Status of Tor proposals and proposal process (March 2008)

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

Hi!  It's been about a year since we announced the new process for
amending the Tor protocol, and it's gone pretty well so far, I think.
It's gotten us better design proposals with more rigor for this stuff
than we've had before, and it's kept us from littering the specs with
stuff that never got implemented.

The message announcing the current process was here:
    http://archives.seul.org/or/dev/Mar-2007/msg00003.html
See that message, and proposal 001, for an overview of how the
proposal process is supposed to work.

Here are the proposals that were accepted and implemented in 0.2.0.x:
   101  Voting on the Tor Directory System
   102  Dropping "opt" from the directory format
   103  Splitting identity key from regularly used signing key
   104  Long and Short Router Descriptors
   122  Network status entries need a new Unnamed flag
   123  Naming authorities automatically create bindings

    These proposals, collectively, describe the improved (more secure
    and less bandwidth-heavy) directory protocol in Tor 0.2.0.x.

   107  Uptime Sanity Checking
   108  Base "Stable" Flag on Mean Time Between Failure
   109  No more than one server per IP address

    These help avoid a set of traffic-hogging attack in the route
    selection algorithm.

   111  Prioritizing local traffic over relayed traffic

    Enables Tor clients to also operate relays while dedicating a certain
    amount of bandwidth to their own traffic (if any).  [Still needs to
    be merged into tor-spec.txt.]

   114  Distributed Storage for Tor Hidden Service Descriptors

    An improved hidden service discovery system by Karsten Loesing to
    remove most of the problems with the older hidden service
    discovery design: descriptor format was a weird binary blob;
    authorities were single points of failure, etc.
     
   119  New PROTOCOLINFO command for controllers

    A way to help controllers tell how Tor expects them to authenticate,
    and what version of the control protocol they're supposed to speak.

   125  Behavior for bridge users, bridge relays, and bridge authorities

    Specifies the basic's of Tor's newer anti-censorship features.
    Needs to be moved into tor-spec.txt, or become a new spec document.

   126  Getting GeoIP data and publishing usage summaries

    Describes a way for the bridge authority/authorities to learn
    which censors are blocking which bridges, without learning info
    that can endanger specific users.

   129  Block Insecure Protocols by Default

    Lets clients warn about (or block) connections to ports that
    almost always risk password exposure.

   105  Version negotiation for the Tor protocol
   106  Checking fewer things during TLS handshakes
   130  Version 2 Tor connection protocol

     These proposals describe our new harder-to-fingerprint TLS
     handshake, and the remaining handshake that we do afterwards.
     Proposal 130 supersedes and draws heavily on proposal 124:
     "Blocking resistant TLS certificate usage".

Here are the currently open/pending proposals.  I'm going to comment a
bit on each; if you want to talk more about one or more of these,
please start a new thread so that this doesn't get horribly confused.
Also remember that all of these have been discussed on or-dev before,
so you'll want to check the archives before replying.

OPEN:
   110  Avoiding infinite length circuits

        Implementation for this is multi-phased, and in-process.  This
        should get revised to reflect current status and moved to
        status ACCEPTED.  Marking as NEEDS-REVISION.

   113  Simplifying directory authority administration

        I think this is mostly done or superseded by 123.  There are
        issues in its problem section that aren't yet solved, but the
        proposal doesn't really claim to say how to solve them AFAICT.
        New proposals to address the remaining issues would be good,
        though.  Marking as SUPERSEDED.

   115  Two Hop Paths
   116  Two hop paths from entry guards

        These both are probably dead at this point: there's been no
        activity for some while.  Both have uncertain anonymity
        implications, especially in light of new path features (like
        bridges) and possible scalability features arma has in mind.
        If anybody wants to resurrect them, a first step will be a
        really thorough analysis of what different attackers can do
        against them.  Marking as DEAD.

   117  IPv6 exits

        This is a good start but could use some revision.  See earlier
        thread.  I want to merge in IPv6 support in 0.2.1.x, including
        support for both entries and exits, so a revision of this
        proposal is important.  Marking as NEEDS-REVISION.

   120  Suicide descriptors when Tor servers stop

        Needs some revision along with a renaming.  Not a bad idea
        IMO, but we should do some simple analysis to figure out
        how much good it will do us in advance.

   121  Hidden Service Authentication

        Karsten's the go-to person for this one.  I haven't looked at
        it in a while, but the basic idea seems sound and valuable.

NEEDS-RESEARCH:

   118  Advertising multiple ORPorts at once

        Good idea.  We should do something like this, but the proposal
        as-written is terribly fragmentary and gnomic.  What twit
        wrote this?  Oh.  Me.  Changing status to DRAFT.

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

        I need to think more about how I feel about this one.

   128  Families of private bridges

        Roger is working on this.  It seems like a valuable feature
        for certain anti-censorship models.  Once it's out of DRAFT,
        I'll check it out more closely.

   132  A Tor Web Service For Verifying Correct Browser Configuration
   133  Incorporate Unreachable ORs into the Tor Network
   134  More robust consensus voting with diverse authority sets

        See recent discussion on all of these.

Problems and issues with the current proposal process:

  There are some non-optimal issues with the current proposal process.
  These existed in our old non-process too, but they were less obvious
  there.  The worst one, from my POV, is that discussion often dies
  out before consensus is reached or before a proposal is finished.
  The best I can think to do here is to do status mails like this more
  often, and to be more explicit about saying stuff like "this issue
  needs to be fixed IMO for the proposal to be accepted" or "I can't
  revise this to work any time soon. Does anybody else want to try?"

  Other problems are:
    - The process doesn't seem to look far enough future.  We seem
      to be planning for the next release, but not for the next two or
      three years.  This is also a planning issue that should get fixed.
    - It's not always trivial to map proposals to their or-dev
      discussions.
    - Versioning and history could be better kept.
    - I don't think we've made it clear what needs/merits a proposal
      and what doesn't.
    - As far as I can no, nobody is using proposal 098 (A list of
      proposals to write) or 099 (miscellaneous micro-proposals).
      Perhaps they should get fixed or retired.
 
   There are probably other issues too.

In the interest of ending on a positive note:

  Summarizing all the stuff we've talked about here has made me really
  proud of everything that we as a software project have built in Tor
  0.2.0.x.  Many thanks to everyone who helped or participated!

peace,
-- 
Nick