Subject: [dnsext] Validating Next Domain Name field in NSEC record

From: "George Barwood" <[email-masked]>
Date: Wed, 1 Sep 2010 12:44:56 +0100

Is it necessary to validate the Next Domain Name field in an NSEC record
using the Signer Name of the associated RRSIG.

For example, if we have

foo.com. NSEC xyz. ....
foo.com. RRSIG NSEC .... foo.com.

the Next Domain Name is xyz. is invalid since it is not within the zone foo.com.

If a check is not performed, I think an NSEC record like this could be used to falsely
deny the existence of domains that are not within the zone.

I don't think the current standard describes the need for such a check.

I'm not too sure, as I haven't thought about NSEC much recently,
so please accept my apologies in advance if I have got this wrong.

- George

---

From: Alex Bligh <[email-masked]>
Date: Wed, 01 Sep 2010 15:22:58 +0100

> the Next Domain Name is xyz. is invalid since it is not within the zone

I assume you are presuming the signature is correct.

RFC4034 4.1.1
>    The Next Domain field contains the next owner name (in the canonical
>    ordering of the zone) that has authoritative data or contains a
>    delegation point NS RRset; see Section 6.1 for an explanation of
>    canonical ordering.  The value of the Next Domain Name field in the
>    last NSEC record in the zone is the name of the zone apex (the owner
>    name of the zone's SOA RR).  This indicates that the owner name of
>    the NSEC RR is the last name in the canonical ordering of the zone.

Therefore this is an invalid NSEC RR and can't be used to prove
the non-existence of anything.

>From there, doesn't RFC4035 s5.4 tell you all you need - particularly
the bit in ***'s below, as you have not got the complete set of
*necessary* NSEC RRsets.
>    To prove the non-existence of an RRset, the resolver must be able to
>    verify both that the queried RRset does not exist and that no
>    relevant wildcard RRset exists.  Proving this may require more than
>    one NSEC RRset from the zone.  ***If the complete set of necessary NSEC
>    RRsets is not present in a response (perhaps due to message
>    truncation), then a security-aware resolver MUST resend the query in
>    order to attempt to obtain the full collection of NSEC RRs necessary
>    to verify the non-existence of the requested RRset.***  As with all DNS
>    operations, however, the resolver MUST bound the work it puts into
>    answering any particular query.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Wed, 1 Sep 2010 20:16:13 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Wednesday, September 01, 2010 3:22 PM
Subject: Re: [dnsext] Validating Next Domain Name field in NSEC record

> I assume you are presuming the signature is correct.

Yes

> the non-existence of anything.

Right, I think we agree. 

So it seems to be important for validators to detect this invalidity, and as it's
not entirely obvious, it would seem to be a good idea for the standard to state
this explicitly, or implementors may quite easily not realise the check is needed.

I wonder whether all current implementations implement the check.

A paragraph somewhere in

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-11#section-4

would seem appropriate to me.

- George

---

From: Alex Bligh <[email-masked]>
Date: Wed, 01 Sep 2010 20:23:01 +0100

--On 1 September 2010 20:16:13 +0100 George Barwood 
<[email-masked]> wrote:

> So it seems to be important for validators to detect this invalidity, and
> as it's not entirely obvious, it would seem to be a good idea for the
> standard to state this explicitly, or implementors may quite easily not
> realise the check is needed.

But you need to check the NSEC returned covers your QNAME. Else Malory
could simply return any old NSEC from elsewhere in the domain. That check
should surely highlight this particular invalid NSEC? That said, I'm
not sure it's a huge security concern. If an authoritative server returns
a correctly signed NSEC record which is itself broken, then I don't
think they can complain if authenticated denial of existence either
works or fails.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Wed, 1 Sep 2010 20:38:42 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Wednesday, September 01, 2010 8:23 PM
Subject: Re: [dnsext] Validating Next Domain Name field in NSEC record

> think they can complain if authenticated denial of existence either

The attack I have in mind is where an attacker forges a response to the query [ foo.net. A ] with a response

rcode = NXDOMAIN
foo.com. NSEC xyz. ....
foo.com. RRSIG NSEC ...... foo.com.

The NSEC record covers the QNAME, the Signer Name is valid,
the RRSIG will validate against the DNSKEY for foo.com etc.

Only by checking the Next Domain field against the Signer Name in the RRSIG
can the bogosity of the response be detected.

-- George

---

From: Alex Bligh <[email-masked]>
Date: Wed, 01 Sep 2010 23:38:29 +0100

--On 1 September 2010 20:38:42 +0100 George Barwood 
<[email-masked]> wrote:

> Only by checking the Next Domain field against the Signer Name in the
> RRSIG can the bogosity of the response be detected.

What vector allows the attacker sign the munged NSEC record but does
allow him to sign any other arbitrary record? Or are you saying the
signature does not actually match (foo.com. != xyz.com.) in which
case this is just a matter of checking the signature corresponds to
the record.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Thu, 2 Sep 2010 08:47:06 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Thursday, September 02, 2010 7:30 AM
Subject: Re: [dnsext] Validating Next Domain Name field in NSEC record

>>> allow him to sign any other arbitrary record?
>>
>> Did you leave a "not" out in there after "does"?
> 
> yes, sorry.
> 
>> The basic constraint is that a zone can only sign records where the owner
>> name of the signed record is within the zone. The signing zone is
>> indicated by the Signer Name field in the RRSIG. This constraint is not
>> violated by the example.
>>
>> The bogus NSEC record contains (non-existence) information about domains
>> that  are not within the zone, even though the owner name is within the
>> zone. This possibility is I think unique to the NSEC record.
> 
> Right, but it has still been signed by foo.com, yes? So foo.com
> signed something bogus. It now reaps the consequences. Where is
> the attack?

The owner of foo.com is able to assert the non-existence of foo.net
(or indeed any domain at all) in a forged response, when he should
only be able to make assertions about foo.com and subdomains of foo.com.

It's not the worst attack in the world, because for most applications
ServerFail is roughly equivalent to NxDomain, but one can imagine
situations where it does make a difference.

George

---

From: Alex Bligh <[email-masked]>
Date: Thu, 02 Sep 2010 09:45:28 +0100

> only be able to make assertions about foo.com and subdomains of foo.com.

That won't work because the NSEC record "x.foo.com IN NSEC bar.foo.net"
does not cover the foo.net QNAME within the meaning of the RFC section
I quoted. IE the check that tests whether the NSEC record covers the
QNAME should already detect this, as the "complete set of necessary
NSEC RRSETs" (necessary to prove the non-existence of foo.net) is
not present.

-- 
Alex Bligh

---

From: "George Barwood" <[email-masked]>
Date: Thu, 2 Sep 2010 11:35:42 +0100

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "George Barwood" <[email-masked]>; <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Thursday, September 02, 2010 9:45 AM
Subject: Re: [dnsext] Validating Next Domain Name field in NSEC record

> NSEC RRSETs" (necessary to prove the non-existence of foo.net) is

I think what you are saying here is that the standard "technically" covers this case
in a rather general and implicit way.

However the style of RFC 4035 is to explicitly list the checks a validator must perform,
so I think an explicit description of this check should have been in that document, and
therefore a note in bis-updates should be made.

- George