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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev