Hi there, > On 19. May 2020, at 19:55, Nick Mathewson <ni...@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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev