Hi there,
On 19. May 2020, at 19:55, Nick Mathewson nickm@torproject.org wrote: If we do decide to finally deprecate v2 onion services, that would be a significant maintenance burden reduced for us, but we'd have to handle the transition carefully. Unlike all the other migrations we've done, there isn't a drop-in path to get the same functionality or keep the same identities with v3 onion services. (And the problem is that there _can't_ be: the identities are strongly tied to 80-bit-truncated-SHA1 and RSA-1024, and the lack of key blinding makes them enumerable.)
I would be exstatic about not having V2 onions around anymore. This would reduce a huge attack vector that incentivizes people to set up malicious relays, which causes huge amounts of time lost, the relays shouldn't have this opportunity to harvest onions, etc.
The main reason I wrote this proposal is this: Any deprecation will probably cause a few users to stick with the old versions of the code for as long as they still work on the network, even if those versions become unsupported and insecure. (After all, people who listen to our advice about what is secure and what isn't have already stopped using v2 onion services.) .
I kind of don't buy the statement in the parentheses, we don't seem to discourage v2 strongly at all afaict. Or is there a warning when you use it or connect to it, for example?
A question, is the HSDir flag for both v2 and v3 onions? If not we could just take that away to break v2 at some point.
Is it time to start this deprecation? If so we need to start working on a timeline, and I agree with Teor that we'd need to figure out how that timeline would work with any walking onions timeline.
I think it should have been started a while ago :)
What do others think?
Cheers Sebastian