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.
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.
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).
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.
Razvan
On Tue, Sep 13, 2016 at 5:40 PM, s7r s7r@sky-ip.org wrote:
On 9/13/2016 3:27 PM, David Goulet wrote: [SNIP]
Hello!
So I 100% share Ivan's concerns. The Hidden Service subsytem of Tor is
quite
complex, lots of pieces need to be glued together and prop224 will add a
lot
of new code (in the 10 of thousand+).
We decided a while back to have the two protocols living side by side at
first
that is current system (v2) and next gen (v3). Relays will need to
support v2
for a while after v3 is release because well not everybody updates their
tor
to the latest. Lots of people have current .onion for which they need a transition to the new generation which includes telling their users
about the
new 52 character one and SSL certs and so on...
The question arise now. Someone running a .onion upgrades her tor that supports v3, should we allow v2 to continue running or transition it to
v3 or
make them both happy together...? We haven't discuss this in depth and
thus we
need to come to a decision before we end up implementating this (which is _soon_). I personally could think that we probably want to offer a
transition
path and thus have maybe a torrc option that controls that behavior
meaning
allowing v2 for which we enable by default at first and then a
subsequent Tor
release will disable it so the user would have to explicitely set it to continue running v2 .onion and then finally rip off v2 entirely in an
other
release thus offering a deprecation path.
However, we are clear that every _new_ service will be v3 and never
again v2
unless it already exists that is we can find a RSA private key
(considering we
do the above of course). And considering both will be supported for a
while,
we'll have to maintain v2 security wise but all new features will go in
v3.
Let's discuss it and together we can come up with a good plan! :)
Thanks! David
v2= old-style (RSA1024) hidden services v3= prop 224 (ed25519) hidden services
I agree with David - it will be problematic to maintain support for both v2 and v3, unlimited in the future. It's clear that we need to offer a reasonable transition period, so everyone can upgrade and move their customers/user bases to the new hidden services, but this doesn't mean v2 should work forever.
v2 hidden services already provide questionable security (from crypto point of view) and in the future things will only get worse for v2. I agree that there are a lot of third party tools working with v2 hidden services (OnionCat, OnionBalance) - these all need to be improved to support prop 224 hidden services.
Considerable resources are spent on v3 hidden services. They are better vs v2 from all points of view, I don't think keeping the v2 code and therefor allowing additional attack surface + creating the task to maintain this old code (v2) in future releases is worth it. This is how things work in software, if something gets upgraded everything upper layer should upgrade as well. Keeping parallel older versions to allow a feature of non-mandatory upgrades is not solid reason for us to do it.
Also, we need to move with Prop 245 (deprecate TAP handshake entirely) and the v2 hidden service code is the blocker for this.
So, my opinion is to deprecate v2 entirely after a sane and reasonable transition period. Apologies to whom this will create headaches - technologically everything can be adjusted to v3 hidden services, it's just some work required -- it's not going to be fun but it's the clean way for the longer term future.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev