Comments on Proposal 105 -- handshake-revision

[Steven Murdoch <tor+Steven.Murdoch@xxxxxxxxxxxx>]

Nick asked me to comment on proposal 105, which is on a revision to
the Tor handshake to add versioning, clock-skew detection and MitM
resistance:
 http://tor.eff.org/svn/trunk/doc/spec/proposals/105-handshake-revision.txt

First two fairly irrelevant points:

Currently NumVersions is both a number of bytes and number of
versions. Would it be neater to change the definition to be just
number of bytes? Then, in the unlikely event we move to >1 byte per
version, the appropriate substring can be decoded. Leaving it as
NumVersions would mean decoding until either the right number of
versions has been reached, or the end of field has been reached.

What do you think about specifying supported version ranges rather
than versions? This relaxes the 380 version limit, but that should
never be a limiting factor. A more important constraint is which
option you think will be easier to implement.

Now some that are less bikeshedy:

The triggering of expecting versions is based on certificate content,
but by the time 105 is implemented, we will not be doing client
certificates. How should this be rephrased? One option is that the
initiator is identified by ciphersuite, and the responder by
certificate content. Another is that the initiator is identified by
the fact that it didn't send a cert (as it was not asked).

If a MitM delays all NETINFO cells sent to a victim, for a really
long time, the receiver will think it is skewed. This isn't a huge
deal, since all that will happen is the user will get a warning, but
it's awkward. A recipient of a NETINFO cell knows that it was sent no
earlier than when the recipient sent its TLS nonce (since the MAC
key depends on that). A node can thus view with suspicion NETINFO cell
received long after it sent it's nonce. Can we get access to this
timestamp (or an adequate alternative) though?

I would suggest the proposal specify precisely the behaviour of a node
on receiving the addresses in the NETINFO cell. Currently it is vague.
I also worry about a host behind NAT. It will send out the internal IP
address in the NETINFO cell, so will not match the IP address that the
receiver sees. How would this case be handled?

Steven.

-- 
w: http://www.cl.cam.ac.uk/users/sjm217/