> On 27 Dec 2018, at 04:10, grarpamp <grarpamp@xxxxxxxxx> wrote: > >> relays have a rather distinct signup and fingerprint pattern >> usually seen for onion attacks. >> ... >> a) If you are an .onion operator I'd like to encourage you to switch to onion >> services version 3 >> ... >> so we can start >> ... >> b) dropping onion version 2 services eventually. > > These are two separate things not necessarily tied together, > thus split for clarity as above. > > The former a) is up to the onion operator based on their needs. > If they have no need for v2, or need v3, they can or should > switch to v3, indeed. > > The latter b) is a feature that some users and operators > in and for onionspace explicitly choose and depend on > to support common apps, and thus would definitely not > like to see yanked out from under them. > Better instead to advertise and update the default onion > semantics for [new] users to v3, and continue support > and backport doable features to v2 until time below... > > Node operators (tor-relays) would continue offering > v2 HSDir support module until such time as the reasons > for choosing v2 by those above are supported in v3 or vN. It's not just about feature parity. Maintaining a reasonable level of security for v2 onion services requires a lot of paid and volunteer time. We need to find bad relays, and block them on directory authorities. If we spend a lot of time blocking relays, we can't spend that time on improving other areas of the tor network. v2 onion services also add a significant amount of load to the Tor network. They use older, inefficient crypto, and they are often targeted by scanners. If we spend a lot of network resources on v2 onion services, then we can't use those resources for more efficient, user-focused traffic. So there are many engineering tradeoffs here. Hopefully, we'll have feature parity on v3 very soon. And then apps will migrate from v2 to v3 (or dual-stack). It's best if we transition slowly, in a planned manner. But we do need to transition in the next few years. Otherwise, we might have to transition quickly due to network or crypto breaks. And that's not a good experience for anyone. > See the threads on this subject on tor-talk, tor-onions, > and tickets for more. > > [CC for inclusion, move there if not relay specific] We try not to have conversations across multiple lists, because it's confusing. It's hard to follow threads, the conversations get split up, and the subjects get mangled. Let's use tor-relays for further discussion. T
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays