On 9/13/2016 6:13 PM, Razvan Dragomirescu wrote:
I disagree with your approach, for comparison's sake, let's say v2 is IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still is to this day, although IPv6 is arguably a much better solution in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a bit of a pipe dream.
Your analogy with IPv4 and IPv6 is unacceptable. IPv6 exists not because IPv4 isn't secure, but because the address space got filled up (internet grew). Of course it has some improvements compared to IPv4 but we cannot say IPv4 has questionable security. I don't think we can speak about security in IP context anyway since there are other protocols where this happens (BGP,TCP etc.). And they do exist in parallel with perspective to migrate to IPv6 entirely in the future (obviously v2 and v3 hidden services will have a migration period also, just not so large because we aren't talking about the entire internet here).
Tor hidden services are a bit "special" because it's hard to poll their owners on their intentions. Some hidden service operators have gone to great lengths to advertise their .onion URLs (v2-style), some have even generated vanity addresses (like Facebook). Forcing a switch to v3 at some point presents a very interesting opportunity for phishing because suddenly a service known and trusted at some address (as opaque as it is) would need to move to an even more opaque address, with no way to determine if the two are really related, run by the same operator, etc. If I were a LE agency, I would immediately grab v3 hidden services, proxy content to existing v2 services and advertise my v3 URL everywhere, then happily monitor traffic.
I am not sure what you mean by grabbing v3 hidden services (generating random ed25519 keys?) and how exactly you are going to proxy anything to the v2 hidden service without access to v2's private key? But regardless of how you have in mind to do this, your points are wrong.
Maintaining v2 services just because operators advertised the v2 onion url style is not an argument. RSA1024 will be easily factored in coming years. We have strong reasons to believe factoring RSA1024 at current moment is not impractical if the target is worth it enough. So, if we allow v2 services forever, we increase the chances for a LE to hijack v2 hidden services by factoring their private keys - this risk is bigger than what you are describing. For the second part, there are plenty ways to prove a v2 hidden service is tied to a v3 one, given you control v2's private key. It provides exactly the same level of cryptographic certification.
All I'm saying is don't remove the v2 services, even if you choose to no longer support them. Some operators (like my company) may choose to continue to patch the v2 areas if required and release the patches to the community at large. Forcing us out altogether would make us drop Tor and start using an alternative network or expending the additional effort to make our services network-agnostic (so no more good PR for Tor).
This doesn't sound good. Would your company ship to its users code that you do not support yourself, but relying on third parties to do so? Relying on a third party company for patches doesn't sound comfortable to me (with all due respect, I am sure your company is able to do it without problems, I just don't think it's professional this way). Rather than trying to spend time to code patches for the old v2 code why not spend that time and make your services compatible with v3 hidden services? OnionBalance and OnionCat will find ways to work with v3 hidden services.
Ivan was right, moving to v3 would be, at least for my project, extremely complex and unwieldy. Ed25519 is not supported by any smartcards I know (but can be "hacked" by manually defining Curve25519 params and converting back and forth). But then we'd have to modify the service re-registration (or wait for OnionBalance to do it), then add another layer for OnionCat-like lookups, etc. It would be far easier to just drop the Tor dependency at that point or centralize it a bit more.
Just my 2 cents, if any hidden service operators wish to chime in, feel free to do so. After all, it's us (them? :) ) that will have to make the changes to their services.
Not only clients. Also, the relays -- hidden service directories -- for example I don't want to host v2 descriptors on my relays after prop 224 is implemented.