Re: NSEC+ and NO

[Peter Koch <pk@TechFak.Uni-Bielefeld.DE>]

don@plugh.daedalus.co.nz wrote:

> That is, if someone asks for foo.a.example with DNSSEC, they'll get a
> referral with a signed DS record; if they ask for foo.b.example, they'll
> get an referral with a signed NSEC record that securely marks the
> delegation as insecure.
> 
> If they ask for foo.c.example, they'll get an NXDOMAIN.  Which is what
> they'd have gut if DNSSEC wasn't in the picture.

If I got that right you're in essence suggesting that the "pointer part"
of the NSEC RR be optional. Instead of having it point "somewhere", I'd use
the target for explicit signalling of this feature, e.g. let it point to
the root domain (yes, that would make a problem in ".") or the owner name
itself (which makes problems in "empty" zones) or abuse the NSEC 'bit' in
the RR list.

However, this would open *all* delegated domains, whether secure or not,
to a DoS because someone could intercept an answer and substitute the
referral by an NXDOMAIN response. Since those are unprotected under this
scheme, there's no way to tell whether or not the delegation really exists
(the answer would have to carry some witnessing of the "NSEC doesn't use
pointer" feature, e.g. per the NSEC of the zone [*])

But, since SERVFAIL or REFUSED could always be spoofed (although usually
not cached), there is already a risk of DoS even with authenticated denial.
The quality of both attacks is different (I just cannot reach, say, a webserver
or I may be made to believe a whole organisation ceased to exist - or at least
lost their domain name) but the quality of this difference could be and even
may have been discussed.
The 'threats' draft and the DNSSEC docset don't discuss this kind of "negative"
response (and I'm not sure they should).

-Peter

[*] As was said earlier in this thread, these "per zone" features have
    their own difficulties because you don't necessarily know the enclosing
    zone, so a delegation could be deeper inside a zone than one level,
    e.g. "sub.sub.example" in "example", but per this feature it could be
    required to use one-sublevel-only delegations.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>