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

Tue Jun 23 22:48:08 UTC 2009

In message <20090623144218.GA1984 at shinkuro.com>, Andrew Sullivan writes:
> 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.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

	Nobody is doubting that it can happen and undoubtedly will
	happen if you turn on dnssec and don't have management
	proceedures for those trust anchors.

	Worse yet however is management saying you MUST use these
	trust anchors and the validator skipping over them.  It's
	like adding a modem to your desktop box inside the firewall
	and "sharing the network" through it.

	In the end no one will have trust anchors for ORG or any
	TLD unless they are grafting on namespace and then it is
	pointless to skip over the trust anchor at the graft point.
	They will have trust anchors for the root and for their own
	company and that is about all.  And the trust anchors for
	the root still have to be managed along with those you learn
	from your employer.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org