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

[Paul Vixie]

In message <73F9EFB8-E651-4283-A706-42C81FC14D45 at virtualized.org>,
David Conrad writes:

> The vast, vast majority of folks neither want nor should need to  
> manage their trust anchors.  The best we can probably hope for is for  
> the vast, vast majority of folks to blindly accept what Microsoft,  
> Apple, Linux distribution packagers, Belkin, Cisco, et al., provide  
> via their standard OS update mechanisms.

+1.

> From: Mark Andrews <marka at isc.org>
> Date: Wed, 24 Jun 2009 16:19:12 +1000
> 
> 	Which will work for the root, maybe with very long overlap
> 	periods for KSKs.  For the rest nameserver operators will
> 	need to take responsability.

practical security -- that is, security that can be and will be practiced
-- must support some level of ignorance by consumers.  early dnssec
implementations (up to and including current BIND9) don't offer nearly
enough "ignorance support" for my taste.  some dnssec implementations
(secure32, sparta, BIND9 9.7) improve this situation.  RFC 5011 will also
improve it.  and we should all expect continuous improvement, ending at
the point where nameserver operators can succeed with dnssec in ignorance.

while i'm sympathetic to the fact that dnssec's actual security will
ultimately depend on nameserver operators taking responsibility, there
are a couple of things which we cannot expect if we also want success.
one is each sysadmin doing key-fu (trust anchor policy) for themselves.
we need a standard there.  as DRC says, most responsibility in this area
will be outsourced to OS vendors.  this is how X.509 works today and
while the model has some demonstrated weaknesses, a more perfect system
would less practical, and even less practiced, where SSL is already not
ubiquitous, and should be.  so i think the right tradeoff is "usability"
even when it means most consumers will possess no "key-fu".