Saving Opportunistic Encryption

[Bill Stewart]

The simplest way to get half-safe opportunistic encryption is the "Open 
Secret" shared secret,
or equivalently, draft-ietf-ipsec-internet-key-00.txt's shared 
secret.  Everybody who wants to use it just adds it to their ipsec's list 
of known shared secrets, and uses it unless something better is 
available.  It doesn't pretend to be MITM-proof, but it's a start.  Doing 
the whole job correctly is much harder, which is why Gilmore's 
do-the-job-correctly-or-bust project didn't achieve the "encrypting X% of 
the net by Christmas", where X>1 and Christmas < 2010.  (This doesn't count 
the VPN market, which is what got the commercial support, even if many of 
the vendors used FreeS/WAN code, and it's a much easier problem even if 
ISAKMP/Oakley is a hard way to do something easy.)

Forward DNS support is widely available, because anybody out there who 
doesn't want to run their own DNS can find a friendly DNS provider who'll 
sell them a subdomain they can use, e.g. 
joecypherpunk.FriendlyDnsProvider.net, and they can even do DNSSEC support 
(though obviously you can't walk the whole tree unless the roots are 
signed.)  No ISP support needed.

Reverse DNS support was pretty much a non-starter, because most ISPs don't 
give the user control over their reverse DNS space even if they bother to 
implement it at all.   They're getting better, but you're still usually 
port123.box456.sfo.example.net, and forget getting DNSSEC support.  You 
*could* make it work by building a separate Reverse DNS tree, like 
D.B.C.A.opportunistic-encryption.org, instead of hanging it off 
D.B.C.A.in-addr.arpa.  You'd still have to get people to populate it, and 
make it scalable and DDOS-proof, but perhaps you could do it.

Reverse DNS also has the problem that it's _not_ a 1:1 matching - a given 
IP address may have many virtual hosts on it, and therefore many domain 
names, and the domain names can be different for email vs. web vs. other 
protocols.  So it can only work on a subset of the application space, even 
if you've got the control you need.

Of course, forward DNS isn't really what you want, and reverse DNS mostly 
is, because there isn't a user interface to your IPSEC interface or routing 
tables, especially if the IPSEC box is some security gateway that the end 
user doesn't even have access to, so unless you want to invent some other 
protocol (not ISAKMP/Oakley/etc.) to seed the IPSEC Security Associations, 
all you've got to work with   is the IP address of a destination, not a name.

It's possible to play hackish workarounds that have the DNS server 
opportunistically fetch DNSSEC information, with the assumption that most 
people only talk to IP addresses that they got from DNS lookups, and it 
even has the performance advantage that you can do the fetch before you 
send out any TCP or UDP packets to the destination instead of stalling and 
risking timeouts.  They're not hugely reliable, but they're a start, 
especially if you're going to fall back to "Open Secret".  They're mainly 
useful for machines that are doing their own IPSEC encryption, rather than 
using some IPSEC gateway/firewall box - otherwise you need to build dodgy 
configurations like running the DNS server on  the IPSEC gateway and making 
sure DNS caching and IPSEC SA caching times are compatible.   Also, working 
at this level means you're not just hacking the kernel, or the kernel plus 
some helper daemons - you're hacking BIND and its competitors, and suddenly 
you become responsible for maintaining them :-)

Another approach is to invent a whole new protocol, separate from 
ISAKMP/Oakley/SKIP/etc., which does a handshake to fetch keys.  It either 
has to hit a server at the destination's IP address, implying a need for 
firewall transparency and compatible address spaces (probably works better 
for transport mode than tunnel mode?), or else have some mechanism for 
finding a key+config server.  Hugh Daniel suggested rehabilitating Finger 
as the end-system protocol (after all, we've long since patched the 
security bugs that the Morris worm used back in 1988).  If you're building 
a non-end-to-end mechanism that uses IP addresses as its lookup, you're 
getting awfully close to reinventing Reverse DNS, or else building some 
other vast coordinated effort with half-vast goals.  On the other hand, if 
you're patching half of ISAKMP/Oakley anyway, might as well patch Photuris, 
which is much smaller, lighter, and more correct.


                 Bill Stewart



----
Bill Stewart  bill.stewart at pobox.com