Proposal statuses for Tor 0.2.1.x [Part 1]
nickm at freehaven.net
Fri Jul 11 17:14:07 UTC 2008
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
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
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
I've revies this with Roger's recommendations and marked it for
Proposal 148: Stream end reasons from the client side should be
This is an obvious and easy one; accept, and possibly backport.
More information about the tor-dev