[tor-dev] Proposal status changes the last 17 months.

Nick Mathewson nickm at freehaven.net
Thu Nov 14 18:35:56 UTC 2013


Here's a summary of the proposals that have changed their status and
become closed, dead, or superseded since the last one of these emails
I sent out (last year).

I'll summarize the current status of open proposals in my next mail.

I'll try to send these out more regularly.

===== Newly DEAD or SUPERSEDED:

146  Add new flag to reflect long-term stability [SUPERSEDED]

     From time to time we get the idea of having clients ship with a
     reasonably recent consensus (or a list of directory mirrors),
     so instead of bootstrapping from one of the authorities, they
     can bootstrap from a regular directory cache.  The problem here
     is that by the time the client is run, most of the directory
     mirrors will be down or will have changed their IP.  This
     proposal tried to address that.

     The applications of this design are achieved by proposal 206
     instead.  Instead of having the authorities track long-term
     stability for nodes that might be useful as directories in a
     fallback consensus, we eliminated the idea of a fallback
     consensus, and just have a DirSource configuration option.

213  Remove stream-level sendmes from the design [DEAD]

     Roger had an idea to improve flow control, then decided it
     wasn't a good one.  See the comments in this proposal for
     more discussion.

===== Implemented in 0.2.3 or earlier

162  Publish the consensus in multiple flavors [FINISHED]

     This one got mostly implemented in 0.2.2, with the
     introduction of microdescriptor consensus, and in 0.2.3,
     where microdescriptors were finished. We never implemented
     the meta-document that was going to describe other, future
     flavors, however.  I should extract that into a new

===== Implemented in 0.2.4

117  IPv6 exits [CLOSED]
208  IPv6 Exits Redux [CLOSED]

     We implemented IPv6 exit support in 0.2.4.x. There are some
     lingering issues not addressed in these proposals -- see
     tickets tagged with "ipv6".

186  Multiple addresses for one OR or bridge [CLOSED]

     The protocol side of this is implemented as part of the IPv6
     work in 0.2.4.  Tor doesn't yet use the full range of
     options that the format allows, however. See for example
     #9729 for work in that area (which needs review!)

198  Restore semantics of TLS ClientHello [CLOSED]

     We did this one in 0.2.4.x.  This put us back on the track
     of being TLS users in good standing, and let us use better
     ciphersuites (like ECDHE ones) than the ones we had picked
     out in v1 and v2 of the link protocol.

200  Adding new, extensible CREATE, EXTEND, and related cells [CLOSED]
216  Improved circuit-creation key exchange [CLOSED]

     These came in 0.2.4.x; the first one allowed us to change
     our circuit handshake; the latter specified the ntor
     handshake that 0.2.4.x clients and later prefer today.

204  Subdomain support for Hidden Service addresses [FINISHED]

     This one allows an (ignored) foo at the front of
     foo.bar.onion, for subdomain support.  Sadly, I bet it will
     never see much use with the introduction of longer onion
     addresses in our next-gen hidden service design.

205  Remove global client-side DNS caching [CLOSED]

     Caching DNS addresses across circuits presented a user
     tagging opportunity, and exposed some linkability across
     circuits. This proposal removed the client-side DNS cache
     entirely for most purposes in 0.2.4.

206  Preconfigured directory sources for bootstrapping [CLOSED]

     This proposal introduces the DirSource option, with 0.2.4
     clients (and later) can be set up with to avoid hammering on
     the authorities during their initial bootstrapping on the

207  Directory guards [CLOSED]

     To avoid client enumeration, this proposal says that clients
     should use a guard .  Implemented in 0.2.4.

214  Allow 4-byte circuit IDs in a new link protocol [CLOSED]

     We've been at risk of having more than 65535 circuits on a
     link for a while now; this proposal increased the size of
     circuit IDs to avoid that.

221  Stop using CREATE_FAST [CLOSED]

     The CREATE_FAST handshake was introduced to avoid using the
     TAP handshake on the first hop of circuits, since the TAP
     circuit extension handshake provides no benefit over the .
     But now that the ntor handshake is (sometimes) available,
     that reasoning no longer holds. Implemented in 0.2.4.

222  Stop sending client timestamps [CLOSED]

     This proposal enumerated all the places in our protocol
     where eavesdroppers, clients, or servers get a view of a
     client or server's current time, and explained how to
     ameliorate or remove those linkability.  Implemented in

=====  Implemented in 0.2.5

217  Tor Extended ORPort Authentication [FINISHED]

     We could use an authentication step for using the extended
     ORPort, to ensure that local connections are coming from an
     authorized pluggable transport. This proposal explains how.
     We implemented this in 0.2.5.x as part of the ExtORPort work.

218  Controller events to better understand connection/circuit usage [CLOSED]

     This one is actually going to be in; it adds
     more controller events for researchers.

More information about the tor-dev mailing list