Saving Opportunistic Encryption
Bill Stewart
bill.stewart at pobox.com
Thu Mar 18 01:46:44 PST 2004
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
More information about the Testlist
mailing list