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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev