Subject: [DNSOP] Empty Non-Terminal vs NXDOMAIN in draft-ietf-dnsop-nsec-aggressiveuse

From: Roy Arends <[email-masked]>
Date: Mon, 10 Oct 2016 20:52:30 +0100

Having read the draft…

How does one distinguish a Empty Non-Terminal NODATA response from an NXDOMAIN response, solely by looking at the NSEC or NSEC3 records. 

There is an attack vector where an RCODE0 can be replaced by RCODE3 while keeping the rest of the response completely intact, causing an aggressive use enabled cache to deny existing records.

These kind of subtleties aren’t described in the draft, as far as I can tell. 

Roy

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Oct 2016 07:39:08 +1100

In message <[email-masked]>, Roy Arends writes:
> Having read the draft
>
> How does one distinguish a Empty Non-Terminal NODATA response from an
> NXDOMAIN response, solely by looking at the NSEC or NSEC3 records.

NSEC:  Find the NSEC record that proves that there are no records
at the given name (note all of the owner, the next domain name and
the bit map need to be examined to do this).  It either the owner
name or the next domain name of that record are a subdomain of the
given name then it is a ENT otherwise it is a NXDOMAIN.

> There is an attack vector where an RCODE0 can be replaced by RCODE3 while
> keeping the rest of the response completely intact, causing an aggressive
> use enabled cache to deny existing records.
>
> These kind of subtleties arent described in the draft, as far as I can
> tell.
>
> Roy
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Mon, 10 Oct 2016 22:24:40 +0100

> given name then it is a ENT otherwise it is a NXDOMAIN.

Thanks Mark.

There should be some guidance to this in the draft.

To be complete, for NSEC3: each empty non-terminal has an NSEC3 record associated with it, so there is always a matching NSEC3 record.

The issue remains with NSEC. It is possible to determine the difference. It is important to determine the difference. This method is not specified in the draft that encourages this local optimisation.

Warmly

Roy

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Oct 2016 09:15:11 +1100

In message <[email-masked]>, Roy Arends writes:
> > In message <[email-masked]>, Roy Arends > writes:
> >> Having read the draft
> >> 
> To be complete, for NSEC3: each empty non-terminal has an NSEC3 record > associated with it, so there is always a matching NSEC3 record.
> 
> The issue remains with NSEC. It is possible to determine the difference. > It is important to determine the difference. This method is not > specified in the draft that encourages this local optimisation.
> 
> Warmly
> 
> Roy

If the NSEC record has not been verified as secure discard it.

If the given name sorts before or matches the NSEC owner name discard
it as it does not prove the NXDOMAIN or ENT.

If the given name is a subdomain of the NSEC owner name and the NS
bit is present and the SOA bit is absent then discard the NSEC as
it is from a parent zone.

If the next domain name sorts after the NSEC owner name and the
given name sorts after or matches next domain name then discard the
NSEC record as it does not prove the NXDOMAIN or ENT.

If the next domain name sorts before or matches the NSEC owner name
and the given name is not a subdomain of the next domain name then
discard the NSEC as it does not prove the NXDOMAIN or ENT.

You now have a NSEC record that proves the NXDOMAIN or ENT.

If the next domain name is a subdomain of the given name you have
a ENT otherwise you have a NXDOMAIN.

> > 
> >> There is an attack vector where an RCODE0 can be replaced by RCODE3 > while
> >> keeping the rest of the response completely intact, causing an > aggressive
> >> These kind of subtleties arent described in the draft, as far as I > can
> >> tell.
> >> 
> >> Roy

---

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Oct 2016 12:24:18 -0400

On Mon, Oct 10, 2016 at 6:15 PM, Mark Andrews <[email-masked]> wrote:
>> >=20
>> >=20
>> > In message <[email-masked]>, Roy Arends =
>> writes:
>> >> Having read the draft
>> >>=20
>> >=20
>> To be complete, for NSEC3: each empty non-terminal has an NSEC3 record =
>> associated with it, so there is always a matching NSEC3 record.
>>
>> The issue remains with NSEC. It is possible to determine the difference. =
>> It is important to determine the difference. This method is not =
>> specified in the draft that encourages this local optimisation.
>>
>> Warmly
>>
>> Roy

Mark, I hope you don't mind, but I stole your below text and included
it as an Appendix in the NSEC document. It's been pushed to GitHub --
https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse

W

>> >=20
>> >> There is an attack vector where an RCODE0 can be replaced by RCODE3 =
>> while
>> >> keeping the rest of the response completely intact, causing an =
>> aggressive
>> >>=20
>> >> These kind of subtleties arent described in the draft, as far as I =
>> can
>> >> tell.
>> >>=20
>> >> Roy
>> >=20
>> > --=20

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf