[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key Management, anyone?
> That's the whole point - we don't need a hardened DNS*. Regular old
> DNS, with new record types to allow it to distribute certificates, would
> be fine.
The Internet-Draft that defines those record types is from the DNSSEC
working group (draft-ietf-dnssec-sexext-01.txt). The new record types
are KEY and SIG. There's also a new NXT record, which is not relevant
to what you are looking for.
You can use these new record types whether or not your resolver
actually checks the signatures on records (what you called hardened
DNS). Code that implements the KEY and SIG record types should appear
under ftp://ftp.vix.com/pub/bind/testing/ within a week or two.
Note that DNSSEC doesn't have the concept of a "certificate". Keys
are carried in one RR and signatures are carried in another. The
combination of a signed key is what most people think of as a
certificate. But in DNSSEC, you can sign other record types, and can
publish keys that aren't signed. I'd guess that when algorithm-ID's are
assigned for e.g. X.509 certs or PGP keys, the entire certificate
(including the key and the non-DNS-related sigs) would appear in the
KEY record.
> It may also be convenient for some people . . . to use DNSSEC
> [as a key certification hierarchy], but there should be no implication that
> DNS-certified keys are required in order to use IPSEC - we as a working
> group should not be that narrowly-focused.
It depends on whether we are trying to build a tightly integrated,
easily understood, easily deployed system -- or another PEM.
We require the use of DNS to run IP (see RFC 1123, Host Requirements,
section 6.1). Why should we not require the use of DNS to run IPSEC?
> *Hardened DNS (DNS-certified keys for the purpose of improving
> the reliability of name-to-address mapping) is quite useful for it's
> own sake. It's just seductively misleading to extend the use of
> "DNS keys created to secure DNS data" into the domain of "keys to
> secure IPSEC traffic".
If you know of a security problem with using the DNS protocols and/or
the RSA/MD5 algorithms to distribute public keys which could be used to
secure IPSEC traffic, then I propose that you announce it. Your last
two messages have cast aspersions, without making specific what your
perceived problem is.
Personally I see an MD5/RSA-secured DNS as an excellent way to publish
and locate keys for IPSEC use. It has most of the attributes we'd
like in such a system, including good use of existing protocols and
code and human knowledge, redundancy, cacheing, local control of
keying material, proven scalability, and a well-distributed workload
for both humans and computers.
> It's interesting that some of those who have strenuously objected to
> single-rooted key heirarchies in the past are now finding that they have
> some operational advantages.
We always knew there were operational advantages. The question is one
of risk for society by centralizing that much power. If distributed
systems can be workably built, they will provide more protection for
the openness of society, making it hard for any single faction
(including the government) to control society or to suppress opposing
points of view. PGP is a successful but not pervasive attempt at such
a system.
DNSSEC is an obvious candidate for publishing IPSEC keys. The
up-and-coming alternative is a system with much more centralized
power. The FBI and NSA are busy designing a certification hierarchy
that requires you to hand your PRIVATE key to a government agent
before your public key can be published. Given that choice, deploying
a self-publishing system that has a root, but with much less power at
the root, is preferable. DNSSEC is such a system.
For me, one factor seems to be that I personally trust Jon Postel to
do the right thing with the root key. I have a lot more trust in him
than in the FBI, NIST, the "good side" of the NSA, or the President.
My guess is that this view is pretty pervasive on the Internet.
John Gilmore
Follow-Ups:
References: