[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: opportunistic encryption deployment problems

On Mon, 6 Aug 2001, Wes Hardaker wrote:
> 3 problems I see with the deployment of opportunistic encryption:
> 1) your method of obtaining information is by reverse DNS lookup,
>    which will provide problems with people who can't control their
>    reverse DNS bindings...

Agreed.  We have some ideas on handling that, but the feedback we're
getting is that it's an even bigger problem than we thought.  Sigh.

The central difficulty is that at the time we need to figure out who to
negotiate with and how to authenticate them, we have *no* information
other than the IP address of the ultimate destination.  It's hard to avoid
starting with a reverse lookup in that situation.

Trying to finesse this by setting up a new tree parallel to the current
inet-addr.arpa reverse tree doesn't seem to really solve anything, alas --
if you follow through all the implications (e.g., how do you decide who is
allowed to update parts of that tree?), you find you have just re-invented
inet-addr.arpa, duplicating all its overheads without actually solving any
of its problems.  At least, that's the way it looked when I analyzed this
option a while back. 

The one possible way out of this is that 99.9% of the time, that IP
address was itself obtained by a very recent DNS lookup of a name, and so
it would be workable to associate the information with that name instead. 

Trouble is, there's no way to ask a DNS server for that!  We need to be
able to ask "what name did you recently map into address a.b.c.d, and what
else did you learn in that lookup?" (since DNSSEC-aware name servers try
to return KEY records along with A records).  There sort of is a way to do
that -- inverse queries -- but it is excessively general, and as a result
nobody implements it and it's increasingly considered obsolete.

> 2) your method of obtaining information is by reverse DNS lookup,
>    which will provide problems with people behind NATs.

Indeed so... but those people are going to have some difficulty using
IPsec anyway, since IPsec does not get along well with NAT.  Also, NAT
is just plain evil, "a botch and a blemish".

That aside, we do have some notions about how to handle this, although
I don't think they made it into the -01 draft (which was done in great
haste).  It's somewhat the same situation as a Road Warrior, which can be
using an IP address it does not "own".  The answer is that (a) it must
originate the call, since there is no way to call in to it, (b) it must
supply enough information via ID payloads to point the other end to DNS
entries for it, and (c) the NAT machinery has to be sufficiently aware of
the situation to NAT things properly.  (Given (c), it is basically the 
same as Road Warrior.)

This is not ideal, but with an atrocity like NAT obstructing your network
access, there is inherently no graceful way. 

> 3) The wider and wider spread use of things like web and other proxies
>    will provide similar problems seen in #2.

Such "stupid packet tricks" do indeed interfere with your use of the
Internet.  Fortunately, encryption prevents most of them anyway, so
widespread opportunistic encryption will make them obsolete.  (The proxy
may intercept your HTTP packets if they go out as plaintext, but there's
not much it can do when they're hidden inside encrypted ESP packets.)

                                                          Henry Spencer
                                                       henry@spsystems.net
References: