Proposal statuses for Tor 0.2.1.x [Part 1]

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

This will be the first of several emails about statuses of various
proposals for Tor 0.2.1.x.  I'm not going to talk about the hidden
service proposals 121, 142, and 143 here (they get their own email),
or about the proposals 144, 149, 150, and 151 (which need more
discussion).

I've recently made nontrivial updates to proposals 110, 118, and 147:
you should check them out if they interest you.

When replying to this, please try to start a separate thread for each
proposal, with the proposal number and title in the header.

Proposal 110: avoiding infinite length circuits

   Accepted.  Part of this is already in 0.2.0.x, and most of the rest
   can be done in 0.2.1.x.  Since the final phase requires us to
   remove support for versions that don't generate RELAY_EARLY cells,
   we'll need delay the final phase of this proposal until all current
   versions are obsolete.  If feasible, we should backport support for
   generating RELAY_EARLY cells to the 0.2.0.x series once it's
   tested, if we can do so safely.

   (Keeping support for old versions indefinitely isn't an option,
   since doing so would continue to enable the very attacks this
   proposal is meant to prevent..)

Proposal 118: Advertising multiple ORPorts at once.

   Revised; recommendation: accept.  I've revised this proposal based
   on conversation with Roger.  It seems pretty easy to build.

Proposal 117: IPv6 exits

   Accepted.  The changes that needed to be made were all in my head,
   or fixed by the revised 118 (which adds ipv6 entry support).

Proposal 120: Shutdown descriptors when Tor servers stop.

   Dead.  The point of this proposal was to give routers a good way to
   get out of the networkstatus early, but proposal 138 (already
   implemented) has achieved this.

Proposal 127: Relaying dirport requests to Tor download site / website

   This stays as a draft proposal.  It's not a totally crazy idea, and
   we need to make distribution as easy as we can, but it might or
   might not be the best way to do it.  Roger thinks we can do better
   if I understand correctly.

Proposal 128: Families of private bridges

   This proposal is partially implemented, and partially dead.  Roger
   will add a note to it, and merge the finished parts into the spec.

Proposal 131: Help users to verify they are using Tor
Proposal 132: A Tor Web Service For Verifying Correct Browser Configuration

   Draft. These are neat ideas for verifying if a user's browser is
   set up to use to use Tor (correctly), and if a user's Tor is
   running at all.  There are pros and cons to both approaches, and
   more design could be needed.  Nobody on the main Tor team seems
   likely to be free to do these on an 0.2.1.x timeframe, but if
   somebody wants to volunteer to tackle them, that'll be great.
   Leaving as Draft.

Proposal 133:  Incorporate Unreachable ORs into the Tor Network

   This proposal discusses changes to allow hosts that aren't able to
   accept incoming connections to nevertheless add themselves to the
   Tor network.  It changes the Tor topology significantly by
   attaching such ORs to only 1/256 of the network.  This isn't
   best-practice from the research community for restricted topologies
   (sqrt(n) seems to be recommended by most papers), so this proposal
   would need revision in any case.  Before we work on that, though,
   we should see how far we can get towards adding unreachable ORs to
   the network by the simpler approaches of notifying users better,
   giving them better instructions, and getting UPNP support working.
   We could also do measurements of how many ORs believe themselves to
   be unreachable, to see what the benefit of a proposal like this
   would be if we did it.  Leaving as Draft.

Proposal 134: More robust consensus voting with diverse authority sets

   Accept.  Reportedly, adding new authorities or removing old ones is
   such a pain that without something like this proposal, we'll never
   do it.  I'm not sure I belive this myself, but I don't run an
   authority of my own, so I'll defer to others' judgment here.

   Parts of this (related to downloading networkstatuses) are already
   implemented.

Proposal 137: Keep controllers informed as Tor bootstraps

   Finished, actually.  Needs to get merged into specs.

Proposal 140:  Provide diffs between consensuses

   Accept.  We've wanted to do something like this for a while, and
   the approach seems basically sane.  I'm not personally looking
   forward to reimplementing a subset ed, but other approaches are
   worse, harder, or more hackish.

Proposal 141: Download server descriptors on demand

   This proposal is a good start, but there are enough open questions
   in it that I'm not comfortable plunging ahead in hopes that the
   answers will appear.  Leaving as draft.  If we get the hard parts
   figured out --particularly the questions in section 3.4-- this
   might be workable for 0.2.1.x.  Leaving as draft for now.

Proposal 145: Separate "suitable as a guard" from "suitable as a new guard"

   Acceptable, but its functionality could be replaced by 141 as noted
   on or-dev discussion.  Leaving Open for now.

Proposal 146: Add new flag to accept long-term stability

   Roger thinks this is a decent idea too, so accept.

Proposal 147: Eliminate the need for v2 directories in generating v3
   directories

   I've revies this with Roger's recommendations and marked it for
   accept.

Proposal 148: Stream end reasons from the client side should be
   uniform

   This is an obvious and easy one; accept, and possibly backport.