[tor-relays] Onion v2 HSDir Support (ref: v3 prop224) [was: fishy fingerprint patterns]

[teor]

> On 27 Dec 2018, at 04:10, grarpamp <grarpamp at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20190104/ced7e957/attachment.sig>