Proposal 105 (handshake revision) needs more thought

[Roger Dingledine]

Hi folks,

Proposal 105 looks like a nice start. For those of you who haven't
already read it, go look at
http://tor.eff.org/svn/trunk/doc/spec/proposals/105-handshake-revision.txt

I've got a few questions/comments, based on trying to write the
"Advertising versions in routerdescs and networkstatuses" section.
Here's some new text, that I'm afraid mainly raises questions.

   Directory authorities can specify which versions are supported by a
   given router using the "v" line in network statuses -- see Section 6.5
   of dir-spec.txt for details.

   We should keep listing a "Tor" version on that line when listing
   old servers that only speak v1 of the link protocol. But for newer
   servers, should we drop the Tor version? How does that reconcile with
   our one data point, which is the begin_dir example, where we need
   to show if we've heard of begin_dir, but it doesn't necessitate a
   "back incompatible" version bump?

   Should we just add more arguments to that same line (ending up with
   "Tor 0.2.0.6-alpha Link 5 Circuit 6") or do we want multiple "v" lines?
   I don't see any strong arguments either way.

   If servers support multiple link versions (e.g. they would include
   several in their VERSIONS cell), do we list all of them here, or
   just the latest, or ...? My guess is we should list just the latest,
   at least until the situation is common where that isn't useful to
   most clients.

   Router descriptors should presumably start including a v line as well,
   so directory authorities have a way of learning what to say.

To elaborate a bit on the begin_dir question, right now clients can
examine the networkstatus to decide whether a given server supports
the begin_dir cell. But that doesn't require a "backward incompatible"
change with the protocol, so by proposal 105 it wouldn't mean a version
bump, so if we don't list a Tor version, how can clients distinguish one
from the other? I see only bad answers to this question ("leave the Tor
version in and keep using it for that", "bump the version number whenever
something changes"), so hopefully there are better answers out there. :)

Also, in the "Security issues" section, the first point says:

     - Do not have clients prefer any protocol version by default
       until that version is widespread.

I assume an implicit choice in here is that when both VERSIONS cells
have been received, the two sides then use the highest version that they
both support. So does the above suggestion mean they shouldn't admit to
supporting it in their VERSIONS cell? How does it become widespread then?

I guess one option is for the initiating server to not admit support for a
new link version until the Tor version that supports it on the receiving
end is sufficiently widespread. Then we can change initiators to start
admitting support, and there will be enough servers around to handle it?

--Roger