[tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.

[Nick Mathewson]

[This isn't done yet, but I've shown it to enough people that I should
share it with the list.]

1. Introduction and background

1.1. Motivation

   Frequently, we find that very old versions of Tor should no longer be
   supported on the network.  To remove relays is easy enough: we
   simply update the directory authorities to stop listing them.

   But to disable clients is harder.  We can do as we did with v1
   directories in Tor 0.2.0.5-alpha, and make them know about no relays
   at all.

   Stepping back -- why should we disable very old clients at all?
   Here are some reasons why:

       * Security.  Anybody who hasn't updated their Tor client in 5
         years is probably vulnerable to who-knows-what attacks.  They
         aren't likely to get anonymity either.

       * Withstand zombie installations.  Some Tors out there were once
         configured to start-on-boot on now-unmaintained systems.  They
         put needless load on the network, and can't be easily disposed
         of.

       * Disable backward-compatibility code.  Currently, Tor supports
         some truly ancient protocols in order to avoid breaking ancient
         versions.  If we disable these protocols without turning off
         the clients that use them, we run the risk that those clients
         will run wild, retrying their connections to the network over
         and over.

   This document describes a designs for use with future versions of Tor
   to better support client deprecation and removal.

   It also describes how we can safely disable existing client versions
   that do not support this proposal.

1.2. History

   Early versions of Tor checked the recommended-versions field in the
   directory to see whether they should keep running.  If they didn't
   recognize

1.3. Goals and requirements

   We need older clients to stop putting (much) load on the network.
   Having them stop working entirely is not sufficient: they need to
   stop working in such a way that they don't keep using up resources.

   In the future, when we disable a client, it would be a good thing to
   provide some means to warn users in advance that they need to
   upgrade, and to provide advice about doing so.

   It might be good to make any disable-switches advisory rather than
   mandatory.

2. Adding a disable-clients switch to consensus documents

   I specify a new consensus element: disable-versions.  It may appear
   any number of times in a consensus document.  The syntax is:

     disable-versions SP SOFTWARE SP ROLE SP DATE SP VERSIONS

     DATE = A date in YYYY-MM-DD format
     ROLE = "relay", or "all".

     SOFTWARE = "Tor"

     VERSIONS = VERSION_RANGE
     VERSIONS = VERSIONS SP VERSION_RANGE

     VERSION_RANGE = VERSION
     VERSION_RANGE = VERSION..VERSION

   [TODO: Specify voting.]

   If the current version is listed in any disabled-versions line for
   its current role, then we should warn the user.  If the current date
   is on after the date specified (starting midnight UTC), we should
   disable the host as follows:

       * If 'relay' is the disabled role, then we should enter
         ClientOnly mode.

       * If 'all' is the disabled role, we should enter DisableNetwork
         mode.

   Note that the DisableNetwork behavior means that once a client is
   disabled, it will not fetch new consensuses.

   To override this, a Tor instance may include a configuration option,
   "IgnoreDisabledVersion VERSION".  It is an error to set this option when
   *not* running with a disabled version.

   [ALTERNATIVE:

   Make RequireLinkProtocol, RequireCircuitProtocol, etc lines for the
   consensus.  Any Tor not supporting those protocols should behave as
   above.  This allows non-Tor implementations to respect these fields.]

3. Disabling current client versions.

3.1. Disabling versions that use the v2 handshake

   These versions (before 0.2.3.6-alpha) use a renegotiation-based
   handshake instead of our current handshake.

   When we detect a renegotiation attempt, we can close the connection,
   or stop reading on it.

3.2. Disabling versions prior to 0.2.4.11-alpha.

   Starting in version Tor 0.2.4.11-alpha, we implemented proposal 214.
   This proposal added a new link protocol, version 4.  Earlier version
   of Tor never support it; newer versions of Tor always advertise their
   support for it.

   We could treat the presence of any link protocol of version 4 or
   later as indicating the presence of 0.2.4.11-alpha.  Upon receiving a
   connection from such a version, we could throttle the bytes we give
   it, drop its circuits, or stop reading.

   [TODO: which?]

3.3. Disabling versions prior to 0.2.5.x

   In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option,
   and always preferring the ntor handshake where available.

   Unfortunately, we can't simply drop all TAP handshakes, since clients
   and relays can still use them in the hidden service protocol.  But
   we could detect these versions by:

        Looking for use of a TAP handshake from an IP not associated
        with with any known relay, or on a connection where the client
        did not authenticate.  (This could be from a bridge, but clients
        don't build circuits that go to an IntroPoint or RendPoint
        directly after a bridge.)

   In response, we can throttle the connection, drop all its circuits,
   or stop reading on it. [TODO: which?]

3.4. Disabling all versions that don't support this proposal

   We should allow 'n' (short for "node") as a synonym for 'r' in
   consensus documents.  Later, if we want to disable all Tor versions
   before today, we can change the consensus algorithm so that the
   consensus (or perhaps only the microdesc consensus) is spelled with
   'n' lines instead of 'r' lines.  This will create a consensus which
   older clients and relays parse as having no nodes.

3.5. In the event of overzealous retries

   We need to be sure that client running versions from 0.2.1 through
   0.2.6 respond gracefully to the responses above.  In particular, we
   need to make sure that they don't continually retry the connections
   that fail in these ways: that would put a lot of extra load on the
   network.

   Above, I recommend stalling connections rather than just closing
   them.  This may prevent the risk of retries, at the risk of using
   additional relay resources.

   To handle something like this, it could be necessary to use the trick
   of 3.4 above.