Subject: Re: NSEC+ and NO

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 04:04:20 +0000

> ...
> In essence, only the parts of the zone containing the live domains
> support authenticated denial; that is, from a registry's point of view,
> we don't really care about what happens to a domain that doesn't exist
> anyway, as long as we can give an authenticated "here is the DS record
> for this delegation", or an authenticated "this domain doesn't have a DS
> record".

this isn't practical.  if the .org people did this, then isc.org would be
subject to downgrade attacks wherein an attacker could insert unsecured
responses into the transaction stream making folks believe that isc.org
did not exist, and the querier would not be able to tell that it had been
spoofed.  i want both positive and negative responses about my parent domain
to be signed and verifiable.

> Is this a compromise that will work for TLD registries?  

i hope not.  not for any registry of which i'd like to be a customer, anyway.

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

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 May 2004 13:56:55 +0200

[email-masked] 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.