Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt

[Roy Arends <Roy.Arends@nominum.com>]

On Fri, 29 Jun 2001, Mats Dufberg wrote:

> On Fri, 29 Jun 2001, Roy Arends wrote:
> 
> > 4) If opt-in is generally conceived as a good idea, should backwards
> > compatibility be enforced by also permitting rfc2535-style zones ? We are
> > already searching for an alternative to sig@child, which is not backward
> > compatible (though of a different level) with rfc2535, next to that,
> > rfc2535 style zone's are not widely deployed. To my knowledge there are
> > some testbeds (cairn, tislabs, sigz, nl.nl, etc) though I've not seen a
> > full deployment of DNSSEC.
> 
> I find the opt-in alternative a goot suggestion, which will ease the
> deployment of DNSsec. But it would be a bad idea not to have the full NXT
> (as defined in RFC 2535).
> 
> During the transition period we will have zone with mixed data (both
> signed and unsigned), but eventually there will be fully signed (secured)
> subtrees.
> 
> If you have a fully signed tree there is not much (if any)  gained from
> the opt-in alternative, but you will not have the fully authenticated
> denial of existence, which means that a fake non-secured subdomain can be
> spoofed.

Note that a malicious user has little if not nothing to gain by faking a
delegation (as in creating a domain that until now did not exist). In
general, a malicious user would want to spoof an existing domain. A
secured existing domain can not be spoofed (regardless if the zone was
opt-in or rfc2535 signed). An unsecured existing domain can always be
spoofed (regardless if the zone was opt-in or rfc2535 signed), because
glue will never be signed.

> Opt-in is good only if full NXT is kept.

Backwards compatibility is no problem, as long as the ambiguity in the NXT
record has to be solved (and I think then using a bit in the KEY does not
solve that).

Regards

Roy Arends
Nominum