[dns-operations] .Org DNSSEC key management policy feedback

[Andrew Sullivan]

On Tue, Jun 23, 2009 at 10:22:31AM +1000, Mark Andrews wrote:

> 	  As a employee you *only* use the
> 	keys the employer gives you.  You don't trust other paths.

On Tue, Jun 23, 2009 at 12:18:14PM +1000, Mark Andrews wrote:
> 
> 	If you stuff up key management things go wrong.

I wish to emphasise that I speak only for myself, and not in any
official capacity, in what follows.  In addition, I'm using Mark's
remarks above as a hook on which to hang this, but they're really just
convenient examples of one position I find fairly commonly held among
those interested in the DNS protocol.

I think that the above views, and their instantiation in code widely
used by naive system administrators all over the Internet, is an
excellent example of why even some competent sysadmins I know think
that the DNS is a horrible mess, incredibly fragile, and mostly to be
left alone while murmuring prayers to the Net gods.  The current
arragement is a bad design, exactly the sort of thing Donald Norman
has drawn attention to.  We are arranging things so that DNSSEC
becomes the blinking 12:00 on the VCR of the Internet.

The DNSSECbis RFCs go out of their way to make it clear that you try
_any path_ you have.  In particular, the beginning of section 5 of RFC
4035 says this:

   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
   DNSKEY RRset and RRSIG RRs from the zone to authenticate _any other_
   RRsets in the zone once the resolver has authenticated a zone's apex
   DNSKEY RRset.  [emphasis mine]

And 5.3.1 says this:

   It is possible for more than one DNSKEY RR to match the conditions
   above.  In this case, the validator cannot predetermine which DNSKEY
   RR to use to authenticate the signature, and it MUST try each
   matching DNSKEY RR until either the signature is validated or the
   validator has run out of matching public keys to try.

Now, I am aware of the argument that that introduction piece refers to
"the apex" rather than the root, and so one might argue that once one
has a different authenticated DNSKEY that functions as an initial
trust anchor, it's in a different tree.  But someone who hasn't been
following the intricacies of the debates in the DNS community could, I
suggest, quite naturally read the RFCs as saying that _any_ trust path
is a good one, and that if you have any authenticated trust anchor and
can construct a chain from there, you're in good shape.  So, a naive
administrator will almost certainly just stop thinking about this
issue at all once the root is signed.

This business of trusting things that are "closer" may be natural in
some cases, but it's clearly very unnatural in other cases.  It adds
an implicit semantics to the right hand side of data depending on
where it is in the tree, something that we DNS weenies complain about
bitterly when cookie-monsters and other such creatures do it.  More
importantly, it is a brittle arrangement: the failure case causes
entire zones to go dark.  Worse still, the response to, "This is a
brittle arrangement that has a catastrophic failure mode," is, "Yes.
Don't do `rm -rf /` as root, either.  Thank you, have a nice day."  It
is this sort of BOFH response that enrages people outside the DNS
community; it is also this sort of user-hostile arrangement of the
operation of the system that presents a significant barrier to the
adoption of DNSSEC.

Suppose that a forward-thinking, ambitious, and security-savvy person
works at MediumCo, and notices that .org is signed today.  Sam Secgeek
gets permission to start validating .org responses for the corporate
network.  Sam sets up a testbed, runs a pilot for 6 months, proves
it's all working, and then sets the system running in production.  Joy
comes to Mudville, and DNSSEC deployment moves along.

Three months later, Sam moves on to a different job, because Sam notes
that things are not well at MediumCo.  Sure enough, MediumCo gets in
trouble and is soon bought up by GiantCo. GiantCo does not have a
DNSSEC plan, or even a plan to find out whether DNSSEC is a thing they
want.  The tiny MediumCo IT department has been swallowed by GiantCo,
and they're all drones doing what they're told in fear of being let
go, or have moved on to another job.  GiantCo's enormous planning
department is meeting to plan the planning meetings for the
integration of the GiantCo and MediumCo networks.  That day, the root
gets signed.  .Org starts rolling its keys and retiring its old key.
Within some period (probably the 5011 hold-down period), the old key
goes away completely from the .org zone, and all of a sudden none of
the former-MediumCo-offices can see any site inside .org.

If you think, for even one instant, that the GiantCo response to this
disaster will not be, "Turn off all DNSSEC forever, it's too
dangerous," then you have not worked in bureaucratic-enough
organizations in your lifetime.  It will be the safest and most
prudent recommendation to make at the time: DNSSEC adoption will still
be small, so validating will not be offering a great deal of value.
At the same time, DNSSEC is another ball in the air, and GiantCo
hasn't had the planning sessions for planning the DNSSEC adoption
study, so they'll just disable it.  The disabling will go in with a
comment, "Turned off because it made .org go dark."  Upper management
will get a report that says, ".Org disappeared for us because of
legacy issues related to DNSSEC in MediumCo infrastructure, which all
needs to be replaced next year with a budget of $largenum."  Nobody
within the next 10 years at GiantCo will want to say "DNSSEC" out
loud unless it is to blame it for global warming or murder of kittens
or last quarter's losses.  

This sort of scenario, repeated at various places on the network,
would be an extremely bad blow for DNSSEC deployment.  Given the way
things are currently arranged, I fully expect it to happen at least a
few times in some places, and the only questions are how often it will
happen and how unrealistic the DNS community will look for having
designed something so brittle.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.