[tor-dev] Future Onion Addresses and Human Factors

[Jeremy Rand]

-----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
>> 
>> https://github.com/Jesse-V/OnioNS-literature
> 
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVxtuSAAoJEAHN/EbZ1y06SVoQAMaa03n2/onHeqtwMzfSRwEO
IzrsyrxLCxJhPCAGH4gvuGkU/rqNJRT4BhwwTCvtgoEnYNWe0dxoc29bNM76KR0f
Ksq5//kgm73sDyyeRw4jxP3SpMzucc1BoyTBEeJdYuL8hdBwBwkOrd32C+ee/7vu
/OUzisy68apzQFHZDlXY5HS6rp+vdOj1uKUglhDM9nSx73kSdOnpvuxZm9PfYdaR
OXBmZ9Lhk8hAYKhoxdTI+I5I8KNiCZV/uWkDSfDs+RUuL2dAvdEcP3uq5lQoIGyO
tOgBqBSpBAk39ihA7YplmhL3YSJcQ4yfo4rY68PDby+sGI/quZ5YGJjOEyKW0TF2
uObuDQz+1ajD/WPiaQ9I6xo2jJE2vQkMrqfCe83YsR8oOmpN3f+YWm/fgs/EoDul
tG50rwr76egQL+EphJFYvH35YKAwoXNowDlTpGMMCanRC0pOoQAdpmyPvJv38E56
mZSC42oeFgV/vjnSEtKBtnthfg6GHap87XHp+nX//Ry5v+fxo9t94QyGUrAxQtLQ
0MJ4athw3QTi8QJYa6y1DktbIze5dStqteBKK+W7EvrXxNS0eJYL9vJvKPEyu75x
dqhzFZTsFjinv9Dgn/YG665WlvVpDkc36wn/Cj6yXP1kT2Prpo+ekmdLFxJUiQ9l
zYtb7Vw4vTw0KOzsrH8E
=UgpZ
-----END PGP SIGNATURE-----