[tor-dev] Proposal 303: When and how to remove support for protocol versions

Wed May 22 18:57:06 UTC 2019

Nick Mathewson:
> Filename: 303-protover-removal-policy.txt
> Title: When and how to remove support for protocol versions
> Author: Nick Mathewson
> Created: 21 May 2019
> Status: Draft
> 
> 1. Background
> 
>    With proposal 264, added support for "subprotocol versions" -- a
>    means to declare which features are required for participation in the
>    Tor network.  We also created a mechanism (refined later in proposal
>    297) for telling Tor clients and relays that they cannot participate
>    effectively in the Tor network, and they need to shut down.
> 
>    In this document, we describe a policy according to which these
>    decisions should be made in practice.
> 
> 2. Recommending features (for clients and relays)
> 
>    A subprotocol version SHOULD become recommended soon after all
>    release series that did not provide it become unsupported (within a
>    month or so).
> 
>    For example, the current oldest LTS release series is 0.2.9; when it
>    becomes unsupported in 2020, the oldest supported release series will
>    be 0.3.5.  Suppose that 0.2.9 supports a subprotocol Cupcake=1, and
>    that all stable 0.3.5.x versions support Cupcake=1-3.  Around one
>    month after the end of 0.2.9 support, Cupcake=3 should become a
>    _recommended_ protocol for clients and relays.
> 
>    Additionally, a feature can become _recommended_ because of security
>    reasons.  If we believe that it is a terrible idea to run an old
>    protocol, we can make it _recommended_ for relays or clients or both.
>    We should not do this lightly, since it will be annoying.

To be clear, "_recommended_" and "_required_" terms here are from
Proposal #264, Section 4, right? Aka the consensus lines?

These only affect WARN-vs-exit behavior by clients and relays that lack
support, right? Clients and relays will still *negotiate* and use
protocol versions that they both have, even if they are not listed as
either recommended or required?

Are there cases where they don't/won't negotiate to use a new protover
field, such as for anonymity fragmentation reasons? How do we handle
those?

(I am trying to gauge the impact of this proposal on our ability to roll
out new features that clients can use right away vs ensure that old
clients and relays can still work. It seems to focus on the latter,
and I want to get a handle on at what expense).

> 3. Requiring features (for relays)
> 
>    We regularly update the directory authorities to require relays to
>    run certain versions of Tor or later.  We generally do this after a
>    short outreach campaign to get as many relays as possible to upgrade.
> 
>    We MAY make a feature required for relays one month after every
>    version without it is obsolete and unsupported, though it is better
>    to wait three months if possible.
> 
>    We SHOULD make a feature required for relays within 12 months after
>    every version without it is obsolete and unsupported.

As a cultural signaling thing, I think it is better to say to relay
operators, "keep your relay's operating system and its Tor up to date,
or please don't run it anymore (aka we'll shut it down for you)."

I think its bad culturally if we signal to people that we need relays so
badly that it doesn't matter if they are unpatched, or if the OS is
unpatched, or if they accidentally publish their relay and ssh keys to a
public github repo. (Relays running on a system that hasn't received any
patches or security updates in 12 months is the administrator diligence
equivalent of publishing admin keys to public github, IMO, if not its
actual functional equivalent).

Not only does it encourage a sloppy mindset about paying attention to
relay systems, it also slows down our development of new protocols, and
impedes major network upgrades.

(As an aside, I would like to take a hard look at the LTS series, and
brainstorm how much it would cost us to provide official, reproducibly
built repos for every distribution whose LTS policies we find expensive
and cumbersome to support.. Or at least do some analysis of which changes
have been or will be extremely expensive or impossible to roll out due
to being blocked on needing to maintain the LTS).

> 4. Requiring features (for clients)
> 
>    Clients take the longest time to update, and are often the least
>    able to fetch upgrades. Because of this, we should be very careful
>    about making subprotocol versions required on clients, and should
>    only do so for fairly compelling reasons.

Is this true? From our Tor Browser metrics (which could use some kind of
totaling), it looks like most Tor Browser users upgrade pretty quickly:
https://metrics.torproject.org/webstats-tb.html

What kinds of clients don't upgrade? I got the impression that it was
mostly things like old botnet cruft that didn't..

>    We SHOULD NOT make a feature required for clients until it has been
>    _recommended_ for clients for at first 9 months.
> 
>    We SHOULD make a feature required for clients if it has been
>    _recommended_ for clients for at least 18 months.

I guess since we're talking about causing clients to exit() in both
these cases, it might be OK to be conservative here...

But again, I am really worried about future network scalability and
performance upgrades getting stalled because we don't want to change
things that fragment client anonymity.. Does that mean that for some
kinds of new features, we can't flip a switch because we're trying to
give clients another 1.5 years *past the EOL of the last LTS* to
upgrade?

I would enjoy a session in Stockholm that walked through how we would
use this proposal and proposal 264 to roll out a handful of involved
changes, such as walking onions, onion service DoS protections, conflux,
explicit congestion control signaling, full datagram Tor, etc. 

It would be awesome if such a session could result in a proposal like
this one, but the flip side: explaining how to use protovers to roll out
involved features so that clients adopt them quickly and safely (and
what sorts of changes can be done quickly, and what sorts of changes
require waiting 4 years for LTS to EOL + 1.5 more years for clients to
update so as not to fragment anonymity).

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190522/b0a82704/attachment.sig>