Comments on Proposal 105 -- handshake-revision

[Nick Mathewson]

On Wed, Oct 17, 2007 at 11:48:54PM +0100, Steven Murdoch wrote:
> 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.

This seems quite sensible.

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

I think ranges would be trickier to implement, and not terribly
necessary.

So far, we're still at "v1" for the OR connection protocol, even after
4 years, and we're only now considering a move to "v2".  In fairness,
we've had backward-compatibility flags days once or twice in the early
days (once to make cells bigger, and once to fix a broken crypto
implementation) but other than that we've managed to do migrations
while keeping older Tor versions compatible -- often long after they
ceased to be secure or maintained.

IMO, as long as we don't treat this proposal as license to mint a new
version for things we could just as well do compatibly, we shouldn't
expect to see hundreds of versions, much less hundreds of
simultaneously implemented versions, for a very long time.

With that, I declare that bikeshed should be painted mauve.

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

Agreed.

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

Oh, this _is_ an interesting bug, and thanks for mentioning it!

Here's a simpler approach that requires less mucking about in the TLS
state: we know (by specification) that the other party won't send us a
NETINFO until after they have received our VERSIONS cell.  Thus, we
can remember when we sent VERSIONS, and not trust the skew information
if the NETINFO cell arrives a long time after we send VERSIONS.

(FWIW, the point of this timestamp is to detect large skews on the
order of half-hours to months.  I'm not sure the attacker can delay
the cell so long without triggering connections to time-out entirely.)

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

Hmm.  On consideration, reporting the address of the interface that
the connection is arriving at is pretty useless, and potentially a
security problem.  (Some people think that knowing a computer's IP
address tells outsiders too much about one's internal network.)

Probably it would be better to have the netinfo contain:
    The other host's apparent address
    This OR's *published* address (or null if this host isn't an OR)

This way, we can achieve both goals of this feature:

  [1] we can use what other people report as our apparent address as a
      last-ditch attempt to guess our address (assuming that enough
      trustworthy people report the same thing)

  [2] We can notice MITMs by realizing that the address we extended to
      is not the official address of this OR.

Of course, for [2], this proposal doesn't play nicely with proposal
118.  I'll try to patch proposal 105 today in a way that fixes the
problems you note and that is also compatible with 118.

many thanks,
-- 
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/20071018/34916135/attachment.pgp>