Subject: Re: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3

From: Matthijs Mekking <[email-masked]>
Date: Fri, 01 Feb 2013 18:26:19 +0100

Hi,

You are right: The errata fixes only the case "No Data Responses,
QTYPE is not DS", but not for the case "Wildcard No Data Responses".

On 02/01/2013 05:55 AM, JINMEI Tatuya / 神明達哉 wrote:
> I have a question related to the recent errata for RFC5155 on empty
> non terminal: 
> http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3441
> 
> What if the empty non terminal is a wildcard?  For example,
> 
> example. ;; zone origin, has SOA, NS, matching NSEC3 etc ;;
> x.example. ;; empty, covered by opt-out NSEC3 ;; *.x.example. ;;
> empty and wildcard, covered by opt-out NSEC3 child.*.x.example. IN
> NS ns.example.com. ;; insecure, no DS, opt-out
> 
> and query is y.x.example./A.  What should be returned in this
> case?

Following the same logic as errata #3441, the closest provable
encloser proof, with the NSEC3 covering the next closer having the
Opt-Out flag set to one.

> 
> Section 7.2.5 of RFC5155 states:
> 
> If there is a wildcard match for QNAME, but QTYPE is not present
> at that name, the response MUST include a closest encloser proof
> for QNAME and MUST include the NSEC3 RR that matches the wildcard.
> This combination proves both that QNAME itself does not exist and
> that a wildcard that matches QNAME does exist.  Note that the
> closest encloser to QNAME MUST be the immediate ancestor of the
> wildcard RR (if this is not the case, then something has gone
> wrong).
> 
> In this case, the closest encloser proof is NSEC3 that matches 
> example. and NSEC3 that covers x.example (that would have
> Opt-Out). But there's no "NSEC3 RR that matches the wildcard".
> Also, the closest (provable) encloser to QNAME (= example.) is not
> the immediate ancestor of the wildcard (RR), which is x.example.
> 
> Is this case included in the discussion that led to the errata?  I 
> re-read the dnsext archive but couldn't be sure (as far as I can
> see the wildcard-related discussions at that time were about
> different issues than this one).  Or is this case excluded by some
> other rules?

I think Section 7.2.5 and Section 8.7 require a similar errata.

Best regards,
  Matthijs

> 
> --- JINMEI, Tatuya Internet Systems Consortium, Inc. 
> _______________________________________________ dnsext mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 5 Feb 2013 15:18:27 -0500

> and query is y.x.example./A.  What should be returned in this case?

If I get the example right the only name in the zone that has a corresponding NSEC3 record is the apex.  So the response would have an RCODE of NoError (meaning a name match happened) and the NSEC3 record indicating that the rest of the zone is subject to opt-out.  From this the validation should deduce that the name was hit, there was no data, but there is no "security" for this because the source of synthesis is an empty non-terminal.

If there were records at the closest encloser, there would be an NSEC3 there, if there were records at the source of synthesis there would be an NSEC3 there (too).

I'm not claiming that I like that, but it is how I read the intention of the RFC+errata.  (Personally I'd not drop the NSEC3's in signing, but the horse has left the barn on that.)  

I don't see a "problem."  Or maybe I don't see the problem yet.  Perhaps the problem is in what the text says needs to be there?

> Is this case included in the discussion that led to the errata?  I

Short answer no.  But I don't see it as a special case.

We know that wildcards and opt-out together will ruffle some feathers.  If I see a domain (using "domain" as the apex of a zone or a label down in a zone that is the last point of NSEC3 in a descent towards a QNAME) that declares it starts the beginning of an opt-out span, then any other expected hash I am told is missing is an empty non-terminal with only NS RRsets in sub-domains.

In this case, with A NSEC3 A SOA NS ... - that tells me any other NSEC3 I'm looking for "is not there."  Therefore every thing in the zone is subject to this RFC 5155 "special case."

If there were any data records inside this, then we'd have NSEC3's as needed - we know we don't have them though because of that first NSEC3.

On Jan 31, 2013, at 23:55, JINMEI Tatuya / 神明達哉 wrote:

> I have a question related to the recent errata for RFC5155 on
> empty non terminal:
> example. ;; zone origin, has SOA, NS, matching NSEC3 etc
> ;; x.example. ;; empty, covered by opt-out NSEC3
> ;; *.x.example. ;; empty and wildcard, covered by opt-out NSEC3
> child.*.x.example. IN NS ns.example.com. ;; insecure, no DS, opt-out
> 
> and query is y.x.example./A.  What should be returned in this case?
> 
>   If there is a wildcard match for QNAME, but QTYPE is not present at
>   that name, the response MUST include a closest encloser proof for
>   QNAME and MUST include the NSEC3 RR that matches the wildcard.  This
>   combination proves both that QNAME itself does not exist and that a
>   wildcard that matches QNAME does exist.  Note that the closest
>   encloser to QNAME MUST be the immediate ancestor of the wildcard RR
>   (if this is not the case, then something has gone wrong).
> 
> example. and NSEC3 that covers x.example (that would have Opt-Out).
> But there's no "NSEC3 RR that matches the wildcard".  Also, the
> closest (provable) encloser to QNAME (= example.) is not the immediate
> ancestor of the wildcard (RR), which is x.example.
> 
> re-read the dnsext archive but couldn't be sure (as far as I can see
> the wildcard-related discussions at that time were about different
> issues than this one).  Or is this case excluded by some other rules?
> 
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 05 Feb 2013 23:20:01 +0100

Hi,

On 02/05/2013 09:18 PM, Edward Lewis wrote:
>> What if the empty non terminal is a wildcard?  For example, and
>> query is y.x.example./A.  What should be returned in this case?
> 
> If I get the example right the only name in the zone that has a 
> corresponding NSEC3 record is the apex.  So the response would have
> an RCODE of NoError (meaning a name match happened) and the NSEC3
> record indicating that the rest of the zone is subject to opt-out.
> From this the validation should deduce that the name was hit, there
> was no data, but there is no "security" for this because the source
> of synthesis is an empty non-terminal.
> 
> If there were records at the closest encloser, there would be an
> NSEC3 there, if there were records at the source of synthesis there
> would be an NSEC3 there (too).
> 
> I'm not claiming that I like that, but it is how I read the
> intention of the RFC+errata.  (Personally I'd not drop the NSEC3's
> in signing, but the horse has left the barn on that.)
> 
> I don't see a "problem."  Or maybe I don't see the problem yet.
> Perhaps the problem is in what the text says needs to be there?

It is a different case, however very similar to the case described in
Section 7.2.3 and 8.5 in RFC 5155. The case in Section 7.2.3 and 8.5
are about No Data Responses, QTYPE is not DS. The case that Jinmei is
describing is the Wildcard No Data Responses, described in Section
7.2.5 and 8.7. These sections also lack the text that is in errata
#3441. But the errata is solely about Section 7.2.3 and 8.5.

> Short answer no.  But I don't see it as a special case.

Though it is described in RFC 5155 as a different case. However the
problem logic is the similar: An NSEC3 is missing at the wildcard
empty non-terminal because the empty non-terminal was derived from an
insecure delegation.

Best regards,
  Matthijs

> 
> We know that wildcards and opt-out together will ruffle some
> feathers. If I see a domain (using "domain" as the apex of a zone
> or a label down in a zone that is the last point of NSEC3 in a
> descent towards a QNAME) that declares it starts the beginning of
> an opt-out span, then any other expected hash I am told is missing
> is an empty non-terminal with only NS RRsets in sub-domains.
> 
> In this case, with A NSEC3 A SOA NS ... - that tells me any other
> NSEC3 I'm looking for "is not there."  Therefore every thing in the
> zone is subject to this RFC 5155 "special case."
> 
> If there were any data records inside this, then we'd have NSEC3's
> as needed - we know we don't have them though because of that first
> NSEC3.
> 
>> empty and wildcard, covered by opt-out NSEC3 child.*.x.example.
>> IN NS ns.example.com. ;; insecure, no DS, opt-out
>> 
>> for QNAME and MUST include the NSEC3 RR that matches the
>> wildcard.  This combination proves both that QNAME itself does
>> not exist and that a wildcard that matches QNAME does exist.
>> Note that the closest encloser to QNAME MUST be the immediate
>> ancestor of the wildcard RR (if this is not the case, then
>> something has gone wrong).
>> 
>> Also, the closest (provable) encloser to QNAME (= example.) is
>> not the immediate ancestor of the wildcard (RR), which is
>> x.example.
>> 
>> Is this case included in the discussion that led to the errata?
>> I re-read the dnsext archive but couldn't be sure (as far as I
>> can see the wildcard-related discussions at that time were about
>> different issues than this one).  Or is this case excluded by
>> some other rules?
>> 
>> list [email-masked] 
Edward Lewis

---

From: Edward Lewis <[email-masked]>
Date: Tue, 5 Feb 2013 23:23:49 -0500

> #3441. But the errata is solely about Section 7.2.3 and 8.5.

Ah, thanks, I got it now.  I was staring too hard at what should be returned and didn't pay attention to the section numbers.

> empty non-terminal because the empty non-terminal was derived from an

Do you suggest another errata filing against the other sections (that is, in addition to the previous errata) or do we need to scrap the previous one and enter a whole new one?

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 06 Feb 2013 08:40:00 +0100

On 02/06/2013 05:23 AM, Edward Lewis wrote:
>> It is a different case, however very similar to the case
>> described in Section 7.2.3 and 8.5 in RFC 5155. The case in
>> Section 7.2.3 and 8.5 are about No Data Responses, QTYPE is not
>> DS. The case that Jinmei is describing is the Wildcard No Data
>> Responses, described in Section 7.2.5 and 8.7. These sections
>> also lack the text that is in errata #3441. But the errata is
>> solely about Section 7.2.3 and 8.5.
>> 
> 
> Ah, thanks, I got it now.  I was staring too hard at what should
> be returned and didn't pay attention to the section numbers.

You are welcome.

> 
>> Though it is described in RFC 5155 as a different case. However
>> the problem logic is the similar: An NSEC3 is missing at the
>> wildcard empty non-terminal because the empty non-terminal was
>> derived from an insecure delegation.
> 
> Do you suggest another errata filing against the other sections
> (that is, in addition to the previous errata) or do we need to
> scrap the previous one and enter a whole new one?

Since the status of the errata is still on reported, perhaps its best
to enter a whole new one.

Best regards,
  Matthijs

Edward Lewis