Comments on Proposal 105 -- handshake-revision

[Roger Dingledine]

On Thu, Oct 18, 2007 at 12:27:58PM -0400, Nick Mathewson wrote:
> 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.

Here's a slight modification and some more details, based on my other
recent post in this thread:

The netinfo cell should contain:
a) The other host's apparent address -- in the case of the initiator,
it's the address we connected to; in the case of the recipient, it's
the address the connection is from.
b) A set of all IP addresses that are officially associated with the
server sending the netinfo cell.

When the connection initiator gets a netinfo cell, he makes sure that
the address he thought he connected to is among the set of IP addresses
in part b. When the connection recipient gets a netinfo cell, he makes
sure that the apparent IP address of the fellow on the other side is
one of the ones in part b. Notice that we're ignoring item a) above
in making these decisions.

And here's where it gets interesting: the current proposal 105 says that
if the IP address doesn't look right, we should close the connection
because we should suspect a mitm. But really, a) the circuit that caused
us to open that connection really did ask for that IP address, and b)
sometimes the IP address lists won't be perfect, and we should tolerate
this rather than mysteriously breaking. So rather than closing that
connection, we should mark it as not_to_primary_address and then treat
it as a normal connection -- so it will continue to work, but we won't
use it for any new circuits that want a "real" connection to that server.

Ok, after having written this, I notice that Nick snuck in a revision to
proposal 118 on Oct 9, though he didn't mention it on or-dev :)
http://archives.seul.org/or/cvs/Oct-2007/msg00103.html
This "suggested rule" appears to match my assumption in my previous post,
which was to be smart when server1 has a descriptor available for server2,
and otherwise be conservative and open a new connection. But doesn't
the NETINFO cell plan mean we don't need to look at (or rely on having)
descriptors at all?

And lest I sound like I've made up my mind: there are an increasing number
of design decisions that seem like they'll be a lot easier if we can
assume that most servers have descriptors of most other servers. It would
mean not needing NETINFO cells at all -- just find a descriptor signed
by the key that's on the other end of the connection, and compare the IP
address to the list of acceptable IP addresses in the descriptor. Maybe
it's time to admit that assumption before we add yet more complexity?

I am leaning toward "no, we'll never succeed at scaling if we make
design decisions that force every server to know about every server."
Anybody else have an opinion?

--Roger