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
Attachment:
pgpMlzZxMuwrn.pgp
Description: PGP signature