[tor-scaling] Summary of 5/31 meeting; next steps

[teor]

> On 7 Jun 2019, at 04:14, Mike Perry <mikeperry at torproject.org> wrote:
> 
> Relay operators are already making some special effort to run a relay.
> Asking them to add a well-run reproducible repo (as a log message
> emitted from 0.2.9 when people try to use it as a relay) is not a big
> additional ask.

Seems like a plan, but how do we get the log message in to the code
of 0.2.8 and earlier, and 0.3.0 to 0.3.3?

We could reject the relay descriptors on authorities, with an
appropriate message. This probably requires a config option, vote and
consensus line, and version-based rejection code.

Or we can just say that authorities will reject relay versions as soon as
they are not recommended. But I think separate knobs might be a good
idea.

As a precaution against fake versions, we should identify major relay
features (like protocols and descriptor lines) and make them
mandatory as well. For example, requiring ed25519 link authentication
for reachability tests would exclude 0.2.9 relays from the consensus.

> As part of this policy, to avoid protocol ossification from the
> client-side, I think we should disregard the implications of a
> vanishingly small 0.2.9 client userbase when making protocol deployment
> decisions. Ex: if only 4 debian/stable clients are the only 4 tor
> clients with an exit-side protocol fingerprint from a Tor version from
> 2017, oh well. #notabug #UseTorBrowser.

I think that's true, but we need to make sure that we aren't creating fast
zombies (a client DoS) with our protocol changes.

> Should we make this into a Tor proposal? We definitely should discuss it
> in Stockholm, perhaps as a part of a relay operators meeting there.

Yes, I think that's a good idea. Let's develop a draft proposal on tor-dev,
then send it to tor-relays and the relay operators meeting for feedback.

T