Proposal 105 (handshake revision) needs more thought

[Nick Mathewson]

On Sun, Mar 11, 2007 at 06:55:34PM -0400, Roger Dingledine wrote:
> 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.

Actually, no:  dir-spec.txt says that

    "v" -- The version of the Tor protocol that this server is
           running.  If the value begins with "Tor" SP, the rest of
           the string is a Tor version number, and the protocol is
           "The Tor protocol as supported by the given version of
           Tor."  Otherwise, if the value begins with some other
           string, Tor has upgraded to a more sophisticated protocol
           versioning system, and the protocol is "a version of the
           Tor protocol more recent than any we recognize."

In other words, if Tor 0.1.2.10-rc sees a "v" line of the form
"Link 1 Circuit 2", it will assume that it is looking at a router more
recent than any version it knows about.  This is exactly what we'd
want it to do, so it's safe to drop the Tor version.


>     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.

I'll muddy things a bit by suggesting as another option that we could
add minor numbers to indicate ignoreable features.

But all in all, I think I like your "Tor 0.2.0.6-alpha Link 5 Circuit
6" option best.  We've used platform numbers for another purpose, too:
bug avoidance.  Sometimes we'll notice, "Hey, Tor version 0.x.y.z has
a major bug with keeping circuits up, let's not use it for FOOBAR
cells" and we'll want to know what version of Tor we're looking at
when we pick our paths.

>    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.

I think the whole list should get included.  This isn't as exorbitant
as it sounds: remember that zlib compresses common strings pretty
well, and the list of supported protocol versions will be the same for
all servers running the same version of Tor.

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

Yep.  This sounds like a job for a new line in router descriptors to
me, maybe an "opt protocols."

  [...]
> 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?

Right.  That's what I had in mind there.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070311/a63c138c/attachment.pgp>