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

[Andrew Sullivan]

On Wed, Jun 24, 2009 at 08:48:08AM +1000, Mark Andrews wrote:

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

The design of DNSSEC is not one in which this "degree of trust"model
is present.  If you want a "trust this key more" model, then there are
a couple possibilities:

1.  Make it part of configuration.  This would be an explicit (and
non-default) option to prioritise keys.  If you add keys to the list,
they always are trusted and nothing else is for the target zone, but
the list ships empty by default.

2.  Infer the additional trust somehow.  This is the mechanism you
seem to be advocating, and against which I am arguing.  

3.  Add some new protocol that signals trustworthiness.

I have already argued that (2) is brittle to the point of being
dangerous to the Internet, that it imputes semantics to RRs where
there should be none, and that it seems to strain hard at the RFCs
defining DNSSECbis.  It therefore seems to me that (1) would be
preferable, in the absence of a DNSSECter effort to provide (3) (I
think that would be a bad idea).

> 	In the end no one will have trust anchors for ORG or any
> 	TLD unless they are grafting on namespace and then it is

Or else no-one will have any trust anchor at all, because everyone is
afraid to turn on DNSSEC since it magically breaks the Internet from
time to time and you have to be one of the 20 people in the world who
follow the details of DNS protocols to understand why.  It's this
initial hurdle I'm focussed on clearing out of the way.  Since there
is a possible path to your long term goal that does not cause the
hurdle to exist, why not take that one?

A

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