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

[Mark Andrews]

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.
 
> 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.

	Your policy model make sense if you *start* doing DNSSEC
	during the bottom up development phase.  If you start in
	the top down phase it doesn't and top down is the long term
	status.

	Mark
 
> kind regards,
> 
> Roy
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org