-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello Tor-Dev,
One of the criticisms of Namecoin which seems to be raised sometimes is that the current domain namespace spec doesn't have a method for a .bit domain owner to prove that they are in control of a .onion. (This is also an issue for .bit domains that point to .i2p.) I'm interested in improving this situation, and am looking for feedback.
First off, I'm curious what the various use cases are for this. The main use case I'm aware of is if a user is aware of a .onion domain already, and is trying to find a human-memorable way to access it. (As far as I can tell, the reverse is not a use case, because if you already trust the .bit domain by name but don't know what .onion you're looking for, presumably Namecoin already does what you want.) Is this correct? Am I missing any other significant use cases?
Second, I'm looking for feedback on my rough approach. The approach I'm looking at right now is to have a Namecoin namespace for .onion backlinks to .bit domains, which is separate from the Namecoin namespace for .bit domains. The backlink namespace would have a name field whose prefix is the .onion domain. We can't prevent a squatter from registering an exact match of the .onion in Namecoin, but by using a prefix and checking the signature on all matches, we can avoid the impact of squatters. (The cost of obtaining new names would be a deterrent for someone trying to flood a .onion prefix with invalid backlinks as a DoS.) The value field would contain a signature of the domain name being pointed to, signed by the .onion key. The .onion key could also sign revocations of an endorsement of a .bit domain; these would also be in that namespace. Is this generally a good approach? I'm aware that cross-protocol attacks need to be carefully considered when signing things with a .onion key -- do you have suggestions on how I can sign a short JSON string of the rough form {"name": "d/domain", "rev": 0} (which corresponds to endorsing domain.bit, and not being a revocation of that .bit domain) in a way that won't open up attacks on the .onion key's normal protocol usage?
I'll write up a more formal spec after feedback is received, just to make sure I'm not missing some important details.
Cheers, - -Jeremy Rand https://namecoin.org