commit 2a9f49b8be4a2ea3253bf6c75608221df2d5462e Author: Nick Mathewson nickm@torproject.org Date: Tue Mar 15 13:36:45 2016 -0400

Apply notes from last month's meeting about prop264,266. --- proposals/264-subprotocol-versions.txt | 26 ++++++---- .../266-removing-current-obsolete-clients.txt | 56 ++++++++++++++++++++++ 2 files changed, 73 insertions(+), 9 deletions(-)

diff --git a/proposals/264-subprotocol-versions.txt b/proposals/264-subprotocol-versions.txt index 240422b..077ae55 100644 --- a/proposals/264-subprotocol-versions.txt +++ b/proposals/264-subprotocol-versions.txt @@ -116,18 +116,19 @@ Status: Open

4. Required protocols

- The consensus may contain three lines: RequiredRelayProtocols, - RecommendedClientProtocols, and RequiredClientProtocols. Each has - the same format as the "protos" line. To vote on these entries, a - protocol/version combination is included only if it is listed by a - majority of the voters. + The consensus may contain four lines: RecommendedRelayProtocols, + RequiredRelayProtocols, RecommendedClientProtocols, and + RequiredClientProtocols. Each has the same format as the "protos" line. + To vote on these entries, a protocol/version combination is included only + if it is listed by a majority of the voters. + + + When a relay lacks a protocol listed in RecommendeddRelayProtocols, it + should warn its operator that the relay is obsolete.

When a relay lacks a protocol listed in RequiredRelayProtocols, it must not attempt to join the network.

- When a relay lacks a protocol listed in RecommendedRelayProtocols, it - should warn its operator that the relay is obsolete.. - When a client lacks a protocol listed in RecommendedClientProtocols, it should warn the user that the client is obsolete.

@@ -139,7 +140,14 @@ Status: Open protocol is required, and it does not implement that protocol, it SHOULD NOT try to fetch a newer consensus.

- The above features should be backported to 0.2.4 and later. + The above features should be backported to 0.2.4 and later, or all the + versions we expect to continue supporting. + + + These lines should be voted on, and should require a supermajority of + authorities (2/3) to make a protocol required. The required protocols + should not be torrc-configurable, but rather should be hardwired in the + Tor code.

5. Current protocols diff --git a/proposals/266-removing-current-obsolete-clients.txt b/proposals/266-removing-current-obsolete-clients.txt index 7a490be..d803c41 100644 --- a/proposals/266-removing-current-obsolete-clients.txt +++ b/proposals/266-removing-current-obsolete-clients.txt @@ -203,3 +203,59 @@ Status: Draft

[This proposal would result in the quietest shutdown.]

+A. How to "pull the switch." + + This is an example timeline of how we could implement 3.3 above, + along with proposal 264. + + TIME 0: + Implement the client/relay side of proposal 264, backported + to every currently existant Tor version that we still + support. + + At the same time, add support for the new consensus type to + all the same Tor versions. + + Don't disable anything yet. + + TIME 1....N: + Encourage all distributions shipping packages for those old + tor versions to upgrade to ones released at Time 0 or later. + + Keep informed of the upgrade status of the clients and + relays on the Tor network. + + + LATER: + At some point after nearly all clients and relays hav + upgraded to the versions released at Time 0 or later, we + could make the switchover to publishing the new consensus + type. + + +B. Next steps. + + We should verify what happens when currently extant client + versions get an empty consensus. This will determine whether + 3.3 will not work. Will they try to fetch a new one from the + authorities at the end of the validity period. + + Another option is from Roger: we could add a flag meaning "ignore + this consensus; it is a poison consensus to kill old Tor + versions." And maybe we could have it signed only by keys that + the current clients won't accept. And we could serve it to old + clients rather than serving them the real consensus. And we + could give it a really high expiration time. New clients + wouldn't believe it. We'd need to flesh this out. + + Another option is also from Roger: Tell new clients about new + locations to fetch directories from. Keep the old locations working + for as long as we want to support them. We'd need to flesh this + out too. + + The timeline above requires us to keep informed of the status of + the different clients and relays attempting to connect to the tor + network. We should make sure we'll actually able to do so. + + http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-02-12-15.01.log.html + has a more full discussion of the above ideas.