Re: Transition from 2535 to opt-in

[Paul A Vixie <vixie@vix.com>]

>       From recent discussions, I have learned that many people
>       think that doing that is reasonable (although I personally
>       do not agree), because:
>       1. the DNS infrastructure is not that vulnarable anymore;

i challenge this.  the dns infrastructure is as vulnerable as it ever was.
in bind8/contrib we ship several "contributed" spoofage tools that work just
as well now as the day they were written, and are not BIND specific at all.

>       2. only few people believe full DNSSEC will ever be deployed;

opt-in doesn't change this.  right now we need to get "." signed and then any
subdomain who publishes a key can be signed and so on.  "opt-in" is for
partial signing of large zones -- only those who have published keys.  what
we need to do is sign the whole thing, including keys when present.  opt-in
is a crutch for COM, which is "hard" to sign.

>       3. there is real value in securing only the RRsets that
> 	 matter (KEYs, APPKEYs, CERT, www.bank.tld, etc.);
>       so, secure only what needs to be secured, and forget the rest.

i challenge this.  SSL is non-universal and even so depends on trusting small
numbers of signing authorities.  DNS is universal and depends only on getting
one's key signed by the parent domain's administrator, of whom there can be an
unlimited number (though only one per domain).  

we need universal capability for certainty across all RR types.  things like
A and PTR are no less authenticity-critical than KEY and CERT and so on.

>       My personal conclusion from this line of thinking is:
>       If ("IF") we go for Opt-In, then go for it all the way, and
>       just forget authenticated denial. This will really make
>       implementation and deployment much simpler, and thus speed
>       it up.

my own conclusion from this is that since arguments for authenticated denial
were made years ago and are still quite compelling, there's no reason to do
opt-in except as a crutch for COM.


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.