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

Re: Key Management, anyone?

	 What smb said (not what you think he said, or what you think
	 he should have said) was that "without DNSSEC, there's an
	 unauthenticated step." I disagree.  PGP provides some level of
	 authentication, without DNSSEC, using plain DNS (plus PGP cert
	 resource records) as a directory service.

I confess that my mind is boggled by the thought of people arguing over
what I did or didn't say or mean.  Makes me feel like some sort of mystic
oracle (but please don't offer me any goat entrails, even as a MIME
attachment...).

Anyway -- I stand by my statement, though I can and will expand on it a
bit, and add a few qualifiers.

The problem we have is the name-to-address mapping.  Without DNSSEC --
or some local mechanism -- this step is completely unauthenticated,
from the perspective of more-or-less vanilla applications that just
call gethostbyname() or equivalent.  The certificate for plugh.com
may be signed by the director of NSA, the head of the (former) KGB,
and John Gilmore -- and it's quite useless if an enemy can slip in
a bogus IP address, since the firewall-based encryptor knows nothing
but the IP address.

To be sure, the DNSSEC tree does have what is (for some purposes) an
inappropriate root.  That can be dealt with by using manually configured
certificates for subtrees of interest.  It may not be a great solution --
and it's certainly not pretty -- but it permits local control and
policies over an important step.  (One could even use a PGP-like web
of trust to distribute sets of zone keys.)  To be sure, this only works
if the implementations of DNSSEC permit local override keys -- but I
think that it does.  If not, it can be changed to do so, without
affecting the over-the-wire protocol.

What are the alternatives, assuming a smart application?  If I want to
talk to plugh.com, I can retrieve its certificate from my own trusted
certificate hierarchy.  I still need its IP address, though, which
implies that I need DNS.  If an enemy can spoof that, through lack of
DNSSEC, we'd have a denial of service situation -- which is still better
than information leakage, but far from ideal.  What we still lack,
though, is some standard way to tell a firewall encryptor, or even
a bump-in-the-cord encryptor, which certificate to use.  There's no
reason we can't design such a protocol, of course, but we don't have
one yet, and we'd have to confront the issue of identifying the proper
outbound encryptor(s).

Would that scheme work?  Sure.  The problem is that it doesn't scale
well on the Internet, if our goal is ubiquitous cryptographic security.
We'd need a separate tree, parallel to the DNS, with operational
characteristics very similar to the DNS, but without a decade or so
of operational experience in the implemenation.

Outbound certificates are much less of a problem, since the local host
or firewall can be told what certificate to use.  My laptop may use
its Fortezza card (well, your laptop might; I don't have a Fortezza
card), a multiuser host might look up the user's certificate or use
a per-host certificate, the firewall can check the source IP address
(and if you can't trust that locally, you have no business using
firewall-based encryption), etc.

In a separate message, I list several important challenge areas for
the IPSEC group.  By challenges, I mean ``problems we have to solve
in order to use IPSEC''.  DNSSEC isn't on the list, since I consider
that to be a solved problem for our purposes.

		--Steve Bellovin