Comments on Proposal 105 -- handshake-revision

[Nick Mathewson]

On Fri, Oct 19, 2007 at 05:58:04AM -0400, Roger Dingledine wrote:
 [...]
> One answer is this complex NETINFO cell that tells both sides who they're
> actually talking to in an authenticated manner.
> 
> How about if we just remember the IP address we connected to (or the
> IP address we got the connection from), and when somebody asks us to
> extend to a given identity fingerprint and he specifies an IP:port that
> doesn't currently have a connection open, then we open a new one. That
> way we refuse to combine circuits that think they're going to different
> places, but we're free to combine circuits that think they're going to
> the same place.

This approach would work, but it (as you note below) it's rather
over-conservative with respect to proposal 118 (multiple ORPorts).

> We become vulnerable to an attacker who actually can redirect traffic
> en route between server1 and server2, but we're in bad shape against
> this attacker anyway.

Right.  That's not the attack we're trying to stop here.

> This "you wanted server2, I see you got his IP address wrong, I'll do what
> you meant instead of what you asked for" behavior is designed, if I recall
> correctly, to tolerate servers on dynamic IP addresses, so even if you
> have an old descriptor it still might work. It's also left-over from the
> days of "server twins", where two servers in different locations shared
> the same identity key. The design choice is 5 years old at this point,
> and probably should have been taken out when we took out server
> twins.

There was another reason to look up connections by ID besides "server
twins": it's not unheard of for a server to wind up with a network
configuration such that the TCP streams it opens seem to originate
from an IP address other than the IP address you use to connect to the
server.

[Ah.  You talk about this below.]

(Also, there's proposal 118, which you talk about below.)

 [...]
> Ok, the next stumbling block: what about those servers who advertise one
> address yet bind to a different one for outbound connections? One option
> for them would be to have them detect the address they actually use,
> and write it in their descriptor. Then server1 can make an exception for
> "well, you asked for server2's primary IP address, but I see I have a
> connection to another one that server2 promised was acceptable too. You'll
> be ok with that."
> 
> (If I'm not mistaken, we would need to do something like this for the
> NETINFO approach too, since we'll have exactly the same problem,
> right?)

I believe so, but we've wanted to detect outgoing addresses for a
while, in order to make tordnsel work better.

> Ok, here's one advantage of the NETINFO approach, in the case of servers
> that have multiple IP addresses: the NETINFO cell can communicate all
> of these IP addresses.

Right.

>                          Otherwise we either divide the anonymity set
> (in practice, there will be one TCP connection for circuits initiated by
> server1 to server2, and a second TCP connection for circuits initiated by
> server2 to server1), or we assume that server1 has a copy of server2's
> descriptor so he can learn that both IP addresses are legit.  (As a
> hack, we could just declare that any IP address on the same /24 as the
> official one is safe enough. This may cut down on the number of duplicate
> connections enough that we're ok with what's left.)

Ewww.  I don't like that hack at all.

>    I'm guessing that
> since we've been trying to maintain the "servers don't need to know about
> the network" goal, the NETINFO cell approach will end up winning. Nick,
> was this what you've been thinking all along, or did I just clarify some
> of our assumptions?

Your email raises a lot of good points, and I'm not sure how many of
them you're wondering if I was "thinking all along".  Let me enumerate
a few things I do agree with:
  - I generally agree with the "list *all* the addresses we think we
    have in the NETINFO cell" approach.

  - I agree that the current policy of "use an existing OR connection
    if the ID matches" is too loose, and needs to be changed to avoid
    MITM.  The conservative fallback position of "use an existing OR
    connection if the ID *and* the IP match the requested ID and IP"
    however, runs into problems like those we outline above.

  - Right now, I think the right approach is probably something like
    "use an existing OR connection if the ID matches, and ANY of the
    following conditions hold:
       - The IP matches the requested IP.
       - We know that the IP we're using is canonical because it was
         listed in the NETINFO cell.
       - We know that the IP we're using is canonical because it was
         listed in the server descriptor."

    The implementation is pretty straightforward: give each OR
    connection a "canonical IP" bit, and set the bit whenever the IP
    in the NETINFO or the serverdesc implies that we're connected to
    an "official" address for the router.  Only extend a circuit over
    an existing connection if the ID and the IP match, or if the
    IDmatches and the IP is "canonical".

    In other words, we should default to doing the "paranoid" thing
    (match by ID and IP).  But since the "paranoid" thing partitions
    circuits and proliferates connections (this wasting sockets), we
    should use NETINFO *and* descriptors to notice when it is safe to
    do the less-paranoid thing (match by ID only).

  - You're right (in your other mail) that we shouldn't close a
    connection just for having a mismatched IP.  I must have been
    having a bad brain day when I said we should.

I think this is different from what I said in my last mail, and
different from what 105 says now, and different from 118 too.  It's a
lot closer to what you say in the mail you sent after this one.

peace,
-- 
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/20071020/2c6c4475/attachment.pgp>