[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[Jeremy Rand]

chelsea komlo:
> Before starting, someone today very kindly pointed me to Prop 271, the
> naming system API for Tor Onion services. Overall, my larger concern is
> whether adding the version in the onion address makes both using and
> distributing onion addresses harder. If the long-term plan is for onion
> addresses to not be used directly, then having the version in the onion
> address is completely fine as this wouldn't present a barrier to entry
> for end users.
> 
[snip]
>
> Yeah! So if the plan is that onion addresses will not be used directly
> by end users and there is an abstraction layer that hides things like
> version upgrade from end users, then going ahead with the current plan
> sounds good.
> 
> However, if there is a chance that end users will consume onion
> addresses directly, then having this discussion seems like a good idea.

Naming systems like Namecoin and OnioNS have better usability due to
being human-meaningful, but they achieve this by sacrificing the
straightforward cryptographic proofs that make .onion names secure.
This doesn't imply that Namecoin and OnioNS are worse for security
overall (I think for a lot of use cases they're more secure than .onion
once you factor in attacks on human psychology), but there are some use
cases where users will want to use .onion directly without a naming
layer.  (I also suspect that this tradeoff is unavoidable to some
extent; Dan Kaminsky and Aaron Swartz made some compelling arguments
that Greg Maxwell's proof of impossibility of decentralized consensus
algorithms also applies to Zooko's Triangle.)

Cheers,
-Jeremy Rand

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170206/a340e3d4/attachment.sig>