Re: Ideas on opt-in, was Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt

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

On Wed, 4 Jul 2001, Edward Lewis wrote:

> At 10:46 PM -0400 7/3/01, Roy Arends wrote:
> >
> >  1 and 2 indicate signed delegations.
> >  3 indicates an unsigned delegation.
> >  4 is of "NXDOMAIN". neither label nor type does exist in this zone.
> >  5 is an authoritative response with a signed RRset in ANSWER.
> >  6 is of "NO DATA".  Label exists, but type does not exist in this zone.
> >  7 is an authoritative response with an unsigned RRset in ANSWER.
>
> >Conclusion:
> >-----------
> >  If the receiving secure resolver does not know whether the zone was
> >  partially signed or fully signed, while a zone was fully signed (aka
> >  rfc2535-style), responses like 3 and 7 are spoofed. It is necessary for
> >  the resolver to know how to interpret the NXT record.
>
> Responses 3 and 7 are open to spoofing.  But this isn't any worse than not
> using DNSSEC at all.

Absolutely, but that is not the point. It's less secure then fullblown
2535. That's why there should be an indication on how to interpret NXT.

> In the case for #3, if the parent is unsigned (as it is today), then the
> zone is spoofed.  When the parent is signed and indicates that the
> delegation exists, albeit unsecured, spoofing this is hard (/impossible).
> However, the contents of the zone are spoofable, as well as the NS set
> given as hints.  (Without TSIG, the NS set could simply be modified to
> pollute caches.)

Absolutely.

> The only loss in this twist is that it is harder to prove a delegation
> should exist. But with or without the twist, you aren't guaranteed any
> data returned.

Yes.

> In the case for #7, the comparison is much simpler.  With opt-in and
> exclusion from the NXT chain, the parent is considered unsecured for this
> record set.  When included, the zone is secured as far as the record set is
> concerned.

Yes.

> Whether this will confuse the resolver, I think that's a yes.  But then
> again, the resolver (in 9.1.3.rc2) didn't seem to understand sig@parent
> (unless we screwed up some other part of the workshop set up).

The problem is that an administrator can secure a zone as thick as he
wants, a resolver can be tricked into accepting an unsecured record (that
in fact does not exist in the zone) because there is no indication how a
NXT should be interpreted. In this case, the resolver could interpret the
NXT as "nothing is signed between the NXT's label and the next domain
name" while the domain holder meant it as "nothing exists between the
NXT's label and the next domain name".

That is a loss (though a minor one, I agree) on security. That is why
there should be an indication how to interpret the NXT record. There is
and was no discussion on that. In the draft the indication is done by
setting bit 4 in the KEY flag field.

This however imposes either "full secured" (bit=0) or "partially secured"
(bit=1) on the whole zone. When the latter is imposed it means there is
absolutely no way of saying "authenticated denial of existence" for some
record.

When setting a bit in the NXT record, and not in KEY, there is still the
distinction between "full secured (denial of existence)" and "partially
secured (denial of signatures)", though not on a zone basis, but on an
record basis.

I think that is a plus.

Regards,

Roy Arends
Nominum