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

Re: Key Management and DNSSEC

> What's going on with key management?  Are there key management
> mailing lists, perhaps?

Jeff Schiller made an executive decision at the last IETF, after
straw-polling the attendees on design criteria.  A small subgroup of
people are currently working on a combined key management proposal,
including designers from SKIP, Oakley, ISAKMP, and Photuris camps.
They have until September 1 to produce a draft acceptable to the
working group.  At that point people could start coding for
interoperability testing.  Jeff says he's prepared to decide among the
current set of candidates if he has to, but he'd prefer an approach
that resolves everyone's issues in a more coherent fashion.  I haven't
heard anything from the subgroup since the day after it was formed,
but they're supposed to not be having their elbows joggled by the
working group anyway.

> Why does Oakley think
> that DNSSEC is ever going to take off? Making something so tentative
> mandatory is a shot in the foot.

I firmly believe that DNSSEC will take off.  I'm putting a lot of
effort to make it take off this summer; it's my job.

I've contributed code to BIND, which will be out in an alpha release
in a week or two, which stores and retrieves SIG and KEY records.  It
does not affect the export status of BIND because it contains no
cryptography; it's just data storage and retrieval.  This will allow
us to bootstrap into DNSSEC soon, with a bit of auxiliary
cryptographic code for generating the keys and signatures offline
(which is where they're supposed to be generated anyway).  For
experimental early deployment of IPSEC, there's no need to check the
signatures on keys; we are still protected against passive attacks
such as packet-sniffing.  When full-blown DNSSEC code is merged and
deployed, we'll be protected against active attacks as well.

I'm also working closely with Trusted Information Systems, which has
been funded by DARPA to build a prototype full-blown DNSSEC
implementation.  I've been working out legal and copyright issues with
them, and hope to soon start helping Paul Vixie merge their code into
BIND.  I'm also on the hook to provide a DNSSEC implementation in
the resolver library, which would check the signatures on DNS RR's;
the TIS code only checks signatures in named, not in the resolver.

I've started DNSSEC deployment discussions with the IANA, which owns
the root domain, and with the various NICs around the world.  So far
everyone has indicated a willingness to generate keys and sign
peoples' records, as soon as the code shows up to implement it.

There is an issue about Network Solutions and its ownership
potentially wanting to undermine Internet security.  It's been pointed
out to me (and I should have known better), that if they wanted to
undermine the DNS, they could provide the wrong RR's as well as the
wrong (or no) signatures.

DNSSEC doesn't prove that everything is trustable; it proves that
records are coming from the organization who has been delegated the
authority for that part of the name space.  If we delegate part of the
name space to someone we don't trust, all the DNSSEC in the world
won't help us.  NSI can make microsoft.com's IP traffic all go to
dockmaster.ncsc.mil any time they want to, and nothing short of the
IANA taking away their delegation of .com will stop that.  And whoever
took over authority for .com would then be in the same position.

Crypto can't create trust.  It merely automates the trust that
already exists for other reasons.

> Besides, DNSSEC doesn't solve
> the problem (who's going to administer it? what about dhcp or
> PPP dynamic addressing?)

The beauty of DNSSEC is that it is administered by the same people who
administer DNS today.  It's a distributed workload that exactly
matches the current DNS zone delegation hierarchy.  DNS is actually
quite an unrecognized heroic feat: a global distributed replicated
cached dynamic database.  It works so well that we just *assume* that
our host names will "of course" map to IP addresses and back.

As for PPP dynamic addressing and DHCP, indeed there is a short-term
problem.  I'm content to start deploying DNSSEC and IPSEC among hosts
who have fixed addresses, while we implement what's needed to support
dynamic addresses; we have to start somewhere.  Paul Vixie has been
working hard on Dynamic DNS Update, for which there is an
Internet-Draft and an implmentation contributed by IBM.  The draft has
not advanced in the standards process because it didn't include
security mechanisms; the ability to update DNS records remotely
without working out the details of authentication could undermine
rather than improve Internet security.  DNSSEC offers perfectly good
security for Dynamic DNS though; as we deploy DNSSEC and get it
operational, we can use DNSSEC SIG records to validate requests for
updates (e.g. from dhcp daemons who have just handed out an address).

In summary, DNSSEC is moving fast.  Very early adopters in the US can
play with it now (see ftp://ftp.tis.com/pub/DNSSEC/README).  In a few
months you'll see scattered operational deployment including a couple
of high-level zones.  By the end of the year I expect most countries'
NICs, and many companies, to be signing their records.

	John Gilmore
References: