-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/08/2015 11:39 PM, Jeff Burdges wrote:
On Sat, 2015-08-08 at 08:44 -0400, Paul Syverson wrote:
One is to produce human meaningful names in association with onion addresses. Coincidentally Jesse has just announce to this same list a beta-test version of OnionNS that he has been working on for the Tor Summer of Privacy. See his message or
OnioNS has a relatively weak adversary model, like Namecoin, right? It's certainly plausible that's good enough for most users, including all financial users, but maybe not everyone.
There are several approaches to improving upon that adversary model :
- Pinning in the Name System - If a name X ever points to a hidden
service key, then X cannot be registered to point to a different hidden service key for 5 years. Alternatively, if our name system involves another private key, then X cannot be registered under another private key for 5 years.
- Pinning/TOFU in the browser - If my browser ever visits X then it
locks either the .onion key and/or the TLS key permanently. Alternatively pin both but one at a time to change. Sounds bad for Tails, etc. though.
- Awareness - Just yell and scream about how OnioNS, Namecoin,
etc. are nowhere near as secure as a .onion address. And especially tell anyone doing journalism, activist, etc. to use full .onion addresses.
I'm not 100% sure what you mean by saying that OnioNS's and Namecoin's adversary models are comparable. To my knowledge, they're quite different in the respect that OnioNS relies on a quorum of directory authorities, while Namecoin relies on a quorum of mining hashpower. Which is "better" probably depends on your threat model. I did a rough calculation about a year ago of how much it would cost to buy ASIC miners that could 51%-attack Namecoin, and it came out to just under a billion USD. Of course, a real-world attacker would (in my estimate) probably be more likely to try to compromise existing miners (via either technical attacks, extortion/blackmail/bribery, or legal pressure). Note that right now -- though hopefully not in the future - -- this kind of attack is easier than it should be because a majority of Bitcoin hashpower (and with it Namecoin) is located in China. I'm not sure about OnioNS's design, but in Namecoin's design, a 51% attack is easily detectable (you'll see blocks getting orphaned in a way that makes a targeted name not get renewed even though the renewal transaction is clearly visible and being relayed). It's also easily detectable specifically which names were targeted by the attack.
Regarding pinning, there are also some half-formed proposals related to that for Namecoin, which would make a 51% attack ineffective at stealing a name (it would instead simply be a DoS attack on that name, which would cost continued hashpower to sustain). Personally I'd love to see these proposals implemented, although getting the appropriate level of review to make sure everything works as we intend takes some time. (This would be a hardfork to the consensus rules, so it takes a lot of carefulness.)
In any event, security only matters if the end users can effectively use it. An end user will be much more likely to notice when a Namecoin or OnioNS name changes, compared to when a .onion name changes. So this isn't really a clear win for .onion -- it's a tradeoff, and which is more "secure" depends on which end users we're talking about, and what threat model we're dealing with. There are probably a significant number of cases where Namecoin (or OnioNS, or something similar to either) would defend against attacks that .onion wouldn't. (The inverse is, of course, also probably the case.)
Cheers, - -Jeremy Rand