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

[Mark Andrews]

In message <BDDA5135-E57B-4EE5-AC1B-C6E414729E6D at dnss.ec>, Roy Arends writes:
> On Jun 23, 2009, at 9:39 AM, Mark Andrews wrote:
> 
> >
> > In message <1D337EA2-A581-47CE-98AA-E95754465293 at dnss.ec>, Roy  
> > Arends writes:
> >> On Jun 23, 2009, at 3:11 AM, Andrew Sullivan wrote:
> >>
> >>> On Sun, Jun 21, 2009 at 03:24:20PM +0000, bmanning at vacation.karoshi.com
> >>> wrote:
> >>>> On Sun, Jun 21, 2009 at 07:50:47AM -0700, David Conrad wrote:
> >>>
> >>>>> Yes, but until the root is signed, people will still need to  
> >>>>> update
> >>>>> their trust anchors to reflect all the islands of trust, including
> >>>>> the
> >>>>> TLDs, they want to validated.
> >>>
> >>>> 	even then, they might want to keep the .ORG key
> >>>
> >>> I'm rather hoping not.  Given the way BIND prefers the "closest"
> >>> configured trust anchor, I think it will make things less reliable.
> >>> Suppose people decide to keep their existing .org key, and then the
> >>> root is signed, and the key-keepers think, "Good," and stop checking
> >>> for updates.  On the next .org key-roll, all of .org instantly goes
> >>> dark for those people with the stale key.
> >>
> >> That still hasn't been fixed?  It seems wrong and very annoying. In  
> >> my
> >> end user experience, it violates the principle of least astonishment.
> >
> > 	Actually it doesn't.  If you configure a trust-anchor for
> > 	your own company you don't want anything overriding it.
> > 	Having that overridden would be POLA violation.
> >
> > 	Having things break because you stopped managing/tracking
> > 	them is not a POLA violation.
> 
> That is a niche kind of market. It would be nice if this behavior  
> would be configurable, but should not be the default. You seem to be  
> under the impression that this behavior is standardized in some  
> protocol specification, and thus should be the default.

	It is the default for BIND.  It has been for 10 years now.
	Changing the default policy in BIND would be POLA violation.
 
> >> I remember the main counter argument was that folks might want to
> >> configure the .ORG key for everything in and under .ORG, and not  
> >> trust
> >> the root key for .ORG, but do trust the root key for everything else.
> >> Doesn't fly. There might be simple dependencies from domains under  
> >> ORG
> >> on something not ORG. See for instance http://www.links.org/?p=635 on
> >> "who pwns the internet".
> >
> > 	For . and ORG I agree.  For ORG and ISC.ORG I disagree.
> > 	For wattle.id.au (when it is signed) and andrews.wattlet.id.au
> > 	I disagree.  There are couple of hundred zones where your
> > 	policy makes sense.  There are millions where named's default
> > 	policy will make sense.
> 
> Imagine I have configured a key for au and for net.au. The latter key  
> is not updated. Whoops, there goes id.au.

	If you stuff up key management things go wrong.

> > 	Your policy model make sense if you *start* doing DNSSEC
> > 	during the bottom up development phase.
> 
> That is, imho, the phase we're getting into.

	And I'm writing code that will still be in use 10 years
	down the track.  You want a default policy that will be out
	of date in 7 months for ORG.  ORG will be in top-down by
	the end of the year.  COM a little longer but not much.
 
> >  If you start in
> > 	the top down phase it doesn't and top down is the long term
> > 	status.
> 
> By that time, this policy should be configurable, and eventually, the  
> default can be changed on behalf on market demand.

	People need "trust the closest trust anchor only" policy now.

	People will never need "use any possible trust anchor" policy.
	It might be nice to have but it will never be a needed policy.

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