Comments on Proposal 105 -- handshake-revision
nickm at freehaven.net
Thu Oct 18 16:27:58 UTC 2007
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
> 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
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.
> 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:
 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)
 We can notice MITMs by realizing that the address we extended to
is not the official address of this OR.
Of course, for , 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 652 bytes
Desc: not available
More information about the tor-dev