Subject: [dnsext] Protocol Action: 'Domain Name System (DNS) IANA Considerations' to Best Current Practice (draft-ietf-dnsext-rfc6195bis-05.txt)

From: The IESG <[email-masked]>
Date: Thu, 06 Dec 2012 13:11:00 -0800

The IESG has approved the following document:
- 'Domain Name System (DNS) IANA Considerations'
  (draft-ietf-dnsext-rfc6195bis-05.txt) as Best Current Practice

This document is the product of the DNS Extensions Working Group.

The IESG contact persons are Ralph Droms and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/

Technical Summary 

  This document specifies Internet Assigned Number Authority (IANA)
  parameter assignment considerations for the allocation of Domain
  Name System (DNS) resource record types, CLASSes, operation codes,
  error codes, DNS protocol message header bits, and AFSDB resource
  record subtypes.

Working Group Summary 

  This document is to a large extent the same as its predecessor, but
  the working group has made some simplifications in process and these
  were not controversial. There is strong consensus behind this
  document.

Document Quality 

  There are many DNS implementations. This document is high quality
  due to reviews by a number of strong reviewers/experts including
  Alfred Hoenes and Mark Andrews.

Personnel 

  The document Shepherd is Olafur Gudmundsson [email-masked]  Ralph
  Droms is the Responsible Area Director.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Dec 2012 11:22:28 -0500

"A customer reported"  a difference between two implementations' responses for a particular query.  (I.e., this isn't just from a reading of the specs, operationally it was noticed.)  I talked to a few people about this already, even obtained proposed errata text, but wanted to bring this to the open list.

The query that is causing the fuss is asking for an A record at an empty non-terminal in a particular context.  The name is in a zone with DNSSEC on, using NSEC3 and opt-out.  Below the empty non-terminal are opt-out (insecured) delegations.  In RFC 5155, section 7.1, bullet #2 there is a clause that exempts such empty non-terminals from having an NSEC3 record.

What RFC 5155 misses is giving corresponding instructions to the server and verifier concerning this exemption.

Here are proposed changes (that will be filed as an errata at some point) open to discussion.  The origin of the changes is from one of the original editors of RFC 5155 (meaning that it is in keeping with the spirit of RFC 5155.  I've taken the liberty to reorder two paragraphs (in whole) because (in my opinion) it read more naturally the way it is presented.  I.e., if I'm wrong, it'll be reverted.  Again, this is open to conversation.

Here are the proposed changes:

Replace section 7.2.3 with the following.

7.2.3.  No Data Responses, QTYPE is not DS

  If the No Data Response is a result of an empty non-terminal derived 
  from an insecure delegation covered by an Opt-Out NSEC3 RR, the 
  closest provable encloser proof MUST be included in the response.  
  The included NSEC3 RR that covers the "next closer" name for the 
  delegation MUST have the Opt-Out flag set to one. 

  In all other cases, the server MUST include the NSEC3 RR that matches 
  QNAME.  This NSEC3 RR MUST NOT have the bits corresponding to either 
  the QTYPE or CNAME set in its Type Bit Maps field.

Replace section 8.5 with the following.

8.5.  Validating No Data Responses, QTYPE is not DS

  If there is an NSEC3 RR that matches QNAME present, the validator must 
  check that both the QTYPE and the CNAME type are not set in its Type 
  Bit Maps field.

  If there is no NSEC3 RR present that matches QNAME, then the validator 
  MUST verify a closest provable encloser proof for the QNAME.  The 
  validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that 
  covers the "next closer" name to the delegation name. This test covers 
  the case where the response is due to an Empty Non-Terminal derived 
  from an insecure delegation covered by an Opt-Out NSEC3 RR.

  Note that this test also covers the case where the NSEC3 RR exists
  because it corresponds to an empty non-terminal, in which case the
  NSEC3 RR will have an empty Type Bit Maps field.

I do have a question to start off discussion.

Does the exemption apply to an empty non-terminal whose descendants are only insecure delegations or to empty non-terminals whose descendants are exclusively insecure delegations or empty non-terminals?

---

From: Brian Dickson <[email-masked]>
Date: Wed, 12 Dec 2012 15:22:14 -0500

On Wed, Dec 12, 2012 at 11:22 AM, Edward Lewis <[email-masked]> wrote:

> Does the exemption apply to an empty non-terminal whose descendants are
> only insecure delegations or to empty non-terminals whose descendants are
> exclusively insecure delegations or empty non-terminals?
>

I think that the only way to formally distinguish between the two scenarios
is:
o   Something would be the former but not the latter, if there were exactly
one terminal below the non-terminal-in-question, which was an insecure
delegation.
o   Something would be the latter but not the former, if there were
multiple terminals below the non-terminal-in-question, all of which were
insecure delegations.
o   If you have terminal.non-empty1.non-empty2.example.com, which category
does "non-empty2" fall into? I think this ambiguity suggests using the
latter is safer.

IMHO, because omitting the empty non-terminals is a MAY, the validator MUST
handle the absence correctly regardless, and there should be no problem
allowing the zone publisher to do either.

Which means the less-restrictive one, e.g. the latter exemption.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Dec 2012 16:48:18 -0500

I'll begin by admitting I don't understand your message.  So I'll try to ask again.

Yes, it's a MAY.  That means the signer can omit the NSEC3, and that's what matters.  And in the customer's case, the open source signer they are using omits the NSEC3.  (Subtext here - I have no control over the customer's choice nor the design and implementation of the open source code.)

So, let me restate my question.

Using these terms:

"X" is a digit used for convenience
ent"X" - a name that owns no RR set
del"X" - a name that owns an NS set but no DS set
fqdn - a name that goes up to the root
labX - a name that is signed despite opt-out (i.e., has an RR set other than/in addition to NS).

name                  ent in question      does it have NSEC3?
lab1.fqdn.            none                 of course
ent1.fqdn.            node does not exist  it doesn't exist
del1.ent2.fqdn.       ent2.fqdn.           it MAY not, it could
del2.ent3.fqdn.       ent3.fqdn.           it MUST have one
lab2.ent3.fqdn.
del3.ent5.ent4.fqdn.  ent4.fqdn.           not too sure, I guess it MAY not

Upshot - I believe that it is okay to omit the NSEC3 for an ENT whose descendants are ENTs and insecure delegations.

For those following this to this point.  Yes, this is a minor, rare, not that really a big deal case.  I get that.  But it can be fixed.

On Dec 12, 2012, at 15:22, Brian Dickson wrote:

> I think that the only way to formally distinguish between the two scenarios is:
> o   Something would be the former but not the latter, if there were exactly one terminal below the non-terminal-in-question, which was an insecure delegation.
> o   Something would be the latter but not the former, if there were multiple terminals below the non-terminal-in-question, all of which were insecure delegations.
> o   If you have terminal.non-empty1.non-empty2.example.com, which category does "non-empty2" fall into? I think this ambiguity suggests using the latter is safer.
> 
> IMHO, because omitting the empty non-terminals is a MAY, the validator MUST handle the absence correctly regardless, and there should be no problem allowing the zone publisher to do either.
> 

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

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Dec 2012 09:38:09 +0000

Edward Lewis <[email-masked]> wrote:
>
> For those following this to this point.  Yes, this is a minor, rare, not
> that really a big deal case.  I get that.  But it can be fixed.

It might not be all that rare. There are a number of TLDs with bits of
undelegated 2LD hierarchy, such as co.at - though that isn't such a great
example because co.at has a TXT record so avoids the empty non-terminal
case.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 13 Dec 2012 10:07:46 +0000

On Wed, Dec 12, 2012 at 9:48 PM, Edward Lewis <[email-masked]> wrote:
> Upshot - I believe that it is okay to omit the NSEC3 for an ENT whose
> descendants are ENTs and insecure delegations.

Good, because this matches my understanding.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Dec 2012 08:55:40 -0500

I should clarify - configuring these empty non-terminals isn't that rare, as you note, top level domains are rife with them.  What's rare is getting asked for, say, the A record at such a name.  It's not like "$empty-no-terminal/IN/ANY +dnssec" will yield as much data as a name that actually owns records.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 14 Dec 2012 10:40:40 +0100

Hi,

On 12/12/2012 05:22 PM, Edward Lewis wrote:
> "A customer reported"  a difference between two implementations' 
> responses for a particular query.  (I.e., this isn't just from a
> reading of the specs, operationally it was noticed.)  I talked to a
> few people about this already, even obtained proposed errata text,
> but wanted to bring this to the open list.
> 
> The query that is causing the fuss is asking for an A record at an
> empty non-terminal in a particular context.  The name is in a zone
> with DNSSEC on, using NSEC3 and opt-out.  Below the empty
> non-terminal are opt-out (insecured) delegations.  In RFC 5155,
> section 7.1, bullet #2 there is a clause that exempts such empty
> non-terminals from having an NSEC3 record.
> 
> What RFC 5155 misses is giving corresponding instructions to the
> server and verifier concerning this exemption.
> 
> Here are proposed changes (that will be filed as an errata at some 
> point) open to discussion.  The origin of the changes is from one
> of the original editors of RFC 5155 (meaning that it is in keeping
> with the spirit of RFC 5155.  I've taken the liberty to reorder two
> paragraphs (in whole) because (in my opinion) it read more
> naturally the way it is presented.  I.e., if I'm wrong, it'll be
> reverted.  Again, this is open to conversation.
> 
> If the No Data Response is a result of an empty non-terminal
> derived from an insecure delegation covered by an Opt-Out NSEC3 RR,
> the closest provable encloser proof MUST be included in the
> response. The included NSEC3 RR that covers the "next closer" name
> for the delegation MUST have the Opt-Out flag set to one.
> 
> In all other cases, the server MUST include the NSEC3 RR that
> matches QNAME.  This NSEC3 RR MUST NOT have the bits corresponding
> to either the QTYPE or CNAME set in its Type Bit Maps field.

This is new in essence the same behavior as QTYPE is DS, right?

> If there is an NSEC3 RR that matches QNAME present, the validator
> must check that both the QTYPE and the CNAME type are not set in
> its Type Bit Maps field.
> 
> If there is no NSEC3 RR present that matches QNAME, then the
> validator MUST verify a closest provable encloser proof for the
> QNAME.  The validator MUST verify that the Opt-Out bit is set in
> the NSEC3 RR that covers the "next closer" name to the delegation
> name. This test covers the case where the response is due to an
> Empty Non-Terminal derived from an insecure delegation covered by
> an Opt-Out NSEC3 RR.
> 
> Does the exemption apply to an empty non-terminal whose descendants
> are only insecure delegations or to empty non-terminals whose
> descendants are exclusively insecure delegations or empty
> non-terminals?

I am not sure what distinction you are trying to make here.

I think the exemption apply to an empty non-terminal that is derived
from only insecure delegations. It is possible that the insecure
delegation is not the direct descendant of the empty non-terminal
(like in your example with ent4 and ent5 in a later follow-up mail)

Best regards,
  Matthijs

> 
> 
> 
> _______________________________________________ dnsext mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Dec 2012 08:47:16 -0500

> This is new in essence the same behavior as QTYPE is DS, right?

What is new in the errata is, for the server, instructions to include the SOA set and one NSEC3 set which demonstrates that the NSEC3 corresponding to the QNAME is absent.  For the validator, if a response contains these two sets in the authority with no answer, then the answer is valid.  My assumption is that, as for any other name below where security stops, the AD bit would not be set (in the case of a validator being a component of a recursive server).

> (like in your example with ent4 and ent5 in a later follow-up mail)

The question is centered on the last sentence.  I assume that the case as described there would be included in the exemption, i.e., that the exemption is not limited to empty non-terminals that have as descendants only (ONLY) nodes that own only (ONLY) an NS set each.  That is the distinction.

Referring to "an empty non-terminal that is derived from only insecure delegations" I want to be sure that I understand.  (Because the word derived is not one we've used in this context before.)  An empty non-terminal name only exists only because it has descendants.  Exists in the sense that asking for data sets owned by it does not generate an NXDOMAIN and the the existence of the empty non-terminal has a bearing on wild card processing.  If all of the descendants are opt-out insecure delegations, that (I'm assuming) fits your description.  I'd calling restricting the omission of empty non-terminals from the NSEC3 to just such empty non-terminals a "conservative" interpretation.

In (http://www.ietf.org/mail-archive/web/dnsext/current/msg12823.html) Ben notes that the "more liberal" interpretation is what he assumes.  I.e., the descendants of the empty non-terminal can also include empty non-terminals that otherwise qualify for the exemption.

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 17 Dec 2012 12:00:13 +0100

On 12/14/2012 02:47 PM, Edward Lewis wrote:
> What is new in the errata is, for the server, instructions to include
> the SOA set and one NSEC3 set which demonstrates that the NSEC3
> corresponding to the QNAME is absent.

Your proposed errata text says that a closest provable encloser proof
MUST be included. This can be more than one NSEC3 set.

I am asking this because I support this errata. We are going to
implement this in NSD. I want to confirm that the behavior of these new
instructions is the same as 'No Data Responses, QTYPE is DS'. We can
reuse code.

  For the validator, if a response
> contains these two sets in the authority with no answer, then the answer
> is valid.  My assumption is that, as for any other name below where
> security stops, the AD bit would not be set (in the case of a validator
> being a component of a recursive server).
> 
> The question is centered on the last sentence.  I assume that the case
> as described there would be included in the exemption, i.e., that the
> exemption is not limited to empty non-terminals that have as descendants
> only (ONLY) nodes that own only (ONLY) an NS set each.  That is the
> distinction.
> 
> Referring to "an empty non-terminal that is derived from only insecure
> delegations" I want to be sure that I understand.  (Because the word
> derived is not one we've used in this context before.) 

I got the word from RFC 5155, Section 7.1 Zone Signing, bullet 2:

    Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
    the empty non-terminal is only derived from an insecure delegation
    covered by an Opt-Out NSEC3 RR.

 An empty
> non-terminal name only exists only because it has descendants.  Exists
> in the sense that asking for data sets owned by it does not generate an
> NXDOMAIN and the the existence of the empty non-terminal has a bearing
> on wild card processing.  If all of the descendants are opt-out insecure
> delegations, that (I'm assuming) fits your description.  I'd calling
> restricting the omission of empty non-terminals from the NSEC3 to just
> such empty non-terminals a "conservative" interpretation.
> 
> In (http://www.ietf.org/mail-archive/web/dnsext/current/msg12823.html)
> Ben notes that the "more liberal" interpretation is what he assumes.
>  I.e., the descendants of the empty non-terminal can also include empty
> non-terminals that otherwise qualify for the exemption.

I think we are on the same level here. I just want to make clear that
all leaf node should be unsigned delegations. And all ents above are
only derived from an insecure delegation (or more, but not from signed
delegations or other authoritative data).

If the leaf node would contain authoritative data, the ent must have an
NSEC3. If the leaf node would be an empty non-terminal, well that's not
possible: the whole path should not exist, because no ent in that path
has a descendant.

So, I guess I am in the 'liberal camp' as well.

Best regards,
  Matthijs

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Dec 2012 09:47:46 -0500

I wanted to ask this question in it's own thread.

In RFC 5155, a zone can elect to opt-out (from the NSEC3 chain) unsigned delegations and any empty non-terminals that "parent" only unsigned delegations.  But a zone does not have to be consistent - it can have some unsigned delegations in the NSEC3 chain.

Are there any implementations that enable mixing opt-out with normal NSEC3 chain building?

None of the tools I've played with allowed me to pick and choose, offering only a flag that turns the feature "on".

Has anyone run across a use case where picking and choosing is needed or desired?

I'm asking out of curiosity but also realizing that because of the "pick and choose" nature, in many cases an extra NSEC3 record and RRSIG is needed in responses.  That just enlarges the response, not any other damage, but if we are concerned about response size it is worth looking into.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Dec 2012 07:33:53 +1100

In message <[email-masked]>, Edward Lewis writes:
> In RFC 5155, a zone can elect to opt-out (from the NSEC3 chain) unsigned
> delegations and any empty non-terminals that "parent" only unsigned 
> delegations.  But a zone does not have to be consistent - 
> it can have some unsigned delegations in the NSEC3 chain.
> 
> None of the tools I've played with allowed me to pick and choose, 
> offering only a flag that turns the feature "on".

Because there is no rational reason to mix and match.  We are dealing
with hashed names and changing the iteration or salt will change which
names fall within a range when hashed.
 
> Has anyone run across a use case where picking and choosing is needed or 

There won't be.
 
> I'm asking out of curiosity but also realizing that because of the "pick 
> and choose" nature, in many cases an extra NSEC3 record and RRSIG is 
> needed in responses.  That just enlarges the response, not any other 
> damage, but if we are concerned about response size it is worth looking 
> into.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 18 Dec 2012 11:39:05 -0500

This and last week I posted on a topic involving RFC 5155 and what appeared to be missing text.  I think I've reached that proverbial "rock and a hard place" position.  One problem - for some reason people seem to be ditching the open discussion that the WG is supposed to foster.  Most of the replies I have received to my messages have been off-list, making this a headache for me to discern what, at least in my opinion (which is not necessarily representative of the WG) of what should be done.  I encourage folks to speak on-list...

I see that there are two alternatives.  One is to take RFC 5155 as is and fill in the missing text.  The other is to step back and take a look at how RFC 5155 has been put into practice.  It is unfortunate to me that the two alternatives aren't in sync.

One path involves adding a few paragraphs to RFC 5155.  But the problem comes in some details.  There are two questions that remain open, including what NSEC3 records are needed to close off the proof.

I want to interject this piece of commentary.  When DNSSEC was formulated, NSEC was an "optimal" solution to negative answers, "optimal" far as protocol engineering was concerned.  One side effect of enabling zone walking was an undesired side effect which what NSEC3 addresses - but in doing so, we had to "give up something" in terms of needing more bytes in a response.  Another side effect was the huge cost of transitioning into DNSSEC, which the opt-out feature, tacked on to NSEC3 addresses.  In doing so, we had to give up being able to secure the unsigned delegations and we created a conflict with how DNS' wild card mechanism worked.  This isn't meant to be a criticism of RFC 5155, just putting it into context and why it took more than a simple effort to write.

Tradeoffs aside, NSEC3 with opt-out has been a workable solution to two major drawbacks of the original DNSSEC design.  It is deployed in 76 of the 98 signed operational zones at the upper reaches of the DNS hierarchy.  (Those numbers include the root zone, the immediate TLDs but omit the 11 test TLDs in place.  Exact numbers aside though, NSEC3 is deployed in operations.)  The 76 zones represent about 25% of the total top zones - including the non-DNSSEC zones.

But the version of NSEC3 in operations today is a subset of the NSEC3 that is in RFC 5155.  So far as I can tell, no one has fully implemented RFC 5155 functionality.  Which makes me wonder, if we crimped the options, can we solve the holes (here) in a better way.  So snother path to fixing the current problem with RFC 5155 is to remove some of the options available - options that haven't been implemented and cause complications in the processing of the records.  This is something done in other protocols as the documents advance through the standards process, something that rarely, if ever, happens in DNS.  The downside of taking on a more aggressive clean up is that there is code deployed according to the current way things are done.

The first proposed path (adding paragraphs) begins with this, as has already been posted:

There are two other blurbs to add.  First is that the Empty Non-Terminals concerned here include those that have descendant Empty Non-Terminals also eligible for exemption.  And then there is some confusion over having to "verify a closest provable encloser proof" as this means up to 3 NSEC3 RRs are involved.  One demonstrating opt-out is in play, a second that there is no NSEC3 for the name in question, and then a proof about wildcards.  The latter though does not play a role in the processing of the DNS response (ignoring DNSSEC), so that's a bit off the rails.  In addition, there's some looseness when there are "stacked" Empty Non-Terminals - which NSEC3 is used to show that there's no NSEC3 for the desired name.

The other path tries to remedy that, but also is targeted at solving the issue that debugging the problem here was very complex, despite the seemingly simple patch job needed.  Here are some proposed changes to NSEC3 opt-out, which limit its options but bring it in line with what is deployed and implemented.

Restrict a NSEC3 "chain" (defined by the parameters in the NSEC3PARAM record) to being opt-out or not only.  I.e., no longer support spans that are opt-out here and there, every span between NSEC3'd names is opt-out eligible.

Include all Empty Non-Terminals in the NSEC3 chain.  Part of this stems from the signer electing to NSEC3 a name based on something the client cannot verify.  When I first was handed the situation, it was unclear if we had a server malfunction, a signer malfunction, or both, because it was not clear that the data in question was an Empty Non-Terminal over opted-out delegations.  Lacking the ability to zone walk (which is the goal of NSEC3), we could not verify this until we got a look at the zone's contents.

A zone may have multiple NSEC3PARAM records (needed for transitions) and each chain is independent as far as opt-out or not.  Again, this is needed just for transitions as it doesn't make much sense to use both opt-out and regular NSEC3.  This is stated for completeness.

The impact of these "radical" steps is to reduce the number of NSEC3 and RRSIG(NSEC3) in some negative answers.  We still need three in NXDOMAIN situations, so this isn't a terribly great gain but for NoError, NoData cases it can help.  These changes permits DNSSEC code to be called RFC 5155 "fully" compliant - as no one (apparently) has taken time to implement this fully.  Always signing Empty Non-Terminals brings more harmony with wild cards and proofs involving them and by limiting the exemption to only names with NS records and no DS records, that can be verified in periods of troubleshooting.

Comments on list are desired.  Conversation on this is desired.  This is presented as a two way choice, but these are not the only two choices available.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 18 Dec 2012 21:31:29 +0100

Hi,

On 12/18/2012 05:39 PM, Edward Lewis wrote:
<snip>

> to either the QTYPE or CNAME set in its Type Bit Maps field.

I am wondering if for QTYPE is not DS, we need another NSEC3 record,
namely the one covering the wildcard. Example:

del1.ent2.fqdn.

(del1 being an unsigned delegation, ent2 an empty non-terminal)

A query for <AAAA, ent2.fqdn> should result in NODATA, but there is no
matching NSEC3. Do closest encloser proof with closest provable
encloser (NSEC3 matching fqdn.) and next closer (NSEC3 covering
ent2.fqdn.). But because there was no matching NSEC3, we still did not
proof if ent2.fqdn. could have been expanded from *.fqdn. Hence, we
need the NSEC3 denying the source of synthesis.

>  NSEC3 RR will have an empty Type Bit Maps field.

If the NSEC3 covering the wildcard is required, then the validator of
course needs to verify it.

> There are two other blurbs to add.  First is that the Empty 
> Non-Terminals concerned here include those that have descendant
> Empty Non-Terminals also eligible for exemption.  And then there is
> some confusion over having to "verify a closest provable encloser
> proof" as this means up to 3 NSEC3 RRs are involved.  One
> demonstrating opt-out is in play, a second that there is no NSEC3
> for the name in question, and then a proof about wildcards.  The
> latter though does not play a role in the processing of the DNS
> response (ignoring DNSSEC), so that's a bit off the rails.  In
> addition, there's some looseness when there are "stacked" Empty
> Non-Terminals - which NSEC3 is used to show that there's no NSEC3
> for the desired name.

Technically, the proof about wildcards is not part of the closest
encloser proof. You would need 2 NSEC3 records at most: One matching
the closest (provable) encloser, one covering the next closer. The
next closer covering NSEC3 has its Opt-Out bit set, saying the NSEC3
possibly covers insecure delegations (or in this new case: insecure
nodata).

> The other path tries to remedy that, but also is targeted at
> solving the issue that debugging the problem here was very complex,
> despite the seemingly simple patch job needed.  Here are some
> proposed changes to NSEC3 opt-out, which limit its options but
> bring it in line with what is deployed and implemented.
> 
> Restrict a NSEC3 "chain" (defined by the parameters in the
> NSEC3PARAM record) to being opt-out or not only.  I.e., no longer
> support spans that are opt-out here and there, every span between
> NSEC3'd names is opt-out eligible.

Even though there are no implementations (known of) that do the
mixture, I don't see why we would restrict this. Mixture is not what
is causing this problem.

Besides, if some NSEC3s can have the Opt-Out bit clear, because they
do not cover unsigned delegations, it adds a little bit more security
to the zone (less spans that do not assert the (non-)existence of
insecure delegations).

> Include all Empty Non-Terminals in the NSEC3 chain.  Part of this 
> stems from the signer electing to NSEC3 a name based on something
> the client cannot verify.  When I first was handed the situation,
> it was unclear if we had a server malfunction, a signer
> malfunction, or both, because it was not clear that the data in
> question was an Empty Non-Terminal over opted-out delegations.
> Lacking the ability to zone walk (which is the goal of NSEC3), we
> could not verify this until we got a look at the zone's contents.

We played with that thought, because that would make validators happy
right now: Just add the NSEC3 at the empty non-terminal and the
validator can verify the NODATA with a single NSEC3. I honestly think
that is a good alternative. It might be problematic for zones with a
lot of structure, like reverse zones (are they even using NSEC3
Opt-Out?). If there would be consensus on such change, your earlier
proposed errata is also not needed.

> A zone may have multiple NSEC3PARAM records (needed for
> transitions) and each chain is independent as far as opt-out or
> not.  Again, this is needed just for transitions as it doesn't make
> much sense to use both opt-out and regular NSEC3.  This is stated
> for completeness.

I would like to keep chains independent.

> The impact of these "radical" steps is to reduce the number of
> NSEC3 and RRSIG(NSEC3) in some negative answers.  We still need
> three in NXDOMAIN situations, so this isn't a terribly great gain
> but for NoError, NoData cases it can help.  These changes permits
> DNSSEC code to be called RFC 5155 "fully" compliant - as no one
> (apparently) has taken time to implement this fully.  Always
> signing Empty Non-Terminals brings more harmony with wild cards and
> proofs involving them and by limiting the exemption to only names
> with NS records and no DS records, that can be verified in periods
> of troubleshooting.

I think it is rather a strong statement to say that no implementation
is fully compliant. What requirements are lacking in nowadays
implementations?

I do agree that there is a flaw in RFC 5155 (possible for signer to
leave out NSEC3 on empty non-terminal to insecure delegation, but
validator expects it when quering for that empty non-terminal). I
would advise to fix that problem, but not take it as an opportunity to
make more radical changes*.

Best regards,
  Matthijs

*If we do, I know of a whole bunch of other stuff we could do to
reduce the number of NSEC3s needed in responses.

> Comments on list are desired.  Conversation on this is desired.
> This is presented as a two way choice, but these are not the only
> two choices available.
> 
> 
> 
> 
> _______________________________________________ dnsext mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Dec 2012 09:22:02 +1100

> need the NSEC3 denying the source of synthesis.

OPTOUT and wildcards are incompatible with each other.  There is no
way to prove that there wasn't a delegation that should have blocked
the wildcard.

> to the zone (less spans that do not assert the (non-)existence of

In addition to not flipping optout state in a chain, no one implements
selecting which insecure delegations are to be opted out.
Implementations just uses the delegation state secure/insecure to make
the decision.

> proposed errata is also not needed.

NSEC3 doesn't prevent zone walking in zones with a known structure.
The only way to prevent zone walking in these zones is to lie in
your negative responses.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJQ0NKgAAoJEA8yVCPsQCW5SFMH/3D8UC5TwVRDVV/+jB0L7qN8
> qRSGiqNUR84Woy7pO/1rrUnJpb6DQjkmry2Y9kCW1Qw7e660lrP4cQM7YC11bEYR
> j+zDad2Nl58mUNmr8sN8vx6KERHPK2eEzonv+n1K1Cn2FdCEwjv8agMP81k8Y+bq
> io3Z7BdkXIB7OWqjWnmAVwBe6t/0hO/mKSBTramXFm82Kp29dkkjt3NFrxMo67cN
> VV9srM/AwAKR+v1CnLTNx3+ktsQRGjKq6AZw5sW3yR765fEQN5R5/Cc/zqJ3uTC4
> WV+Z47HaCW8Wzx8FwZSuIgKJmLI9Dntbw5FEE7hwXLA19vLJ8KMeQ8LU2VI145o=
> =JYV3
> -----END PGP SIGNATURE-----

---

From: "Blacka, David" <[email-masked]>
Date: Tue, 18 Dec 2012 23:33:03 +0000

>   NSEC3 RR will have an empty Type Bit Maps field.

I would (at least) swap paragraph 3 and 2 here.  The "this test" in "Note that this test" is referring to the test in paragraph 1.

> There are two other blurbs to add.  First is that the Empty Non-Terminals concerned here include those that have descendant Empty Non-Terminals also eligible for exemption.  And then there is some…

I've been a bit confused by your confusion about ENTs with descendant ENTs.  When the text says "an empty non-terminal derived from an insecure delegation", it always seemed clear to me that it covers this case.  That is, both of your ENTs are "derived from an insecure delegation", it doesn't matter that they are nested.

I also don't understand the confusion about which NSEC3s are used: you include the NSEC3 matching the closest provable encloser (IOW, the NSEC3 matching the first ancestor that actually has one), and the NSEC3 covering the "next closest name".  That means you would use the same NSEC3s in the responses for all of the generated ENTs.  This is not "loose".

The "verify a closest provable encloser proof" is described in section 8.3 ("Closest Encloser Proof").  If you read that section, it only talks about *two* NSEC3 records (on purpose.)  You only need the third in an NXDOMAIN response.  I can understand some confusion, however, about *why* we don't include the wildcard-covering NSEC3 in opt-out NODATA cases.  I think MarkA explained that better than I might have.

> Restrict a NSEC3 "chain" (defined by the parameters in the NSEC3PARAM record) to being opt-out or not only.  I.e., no longer support spans that are opt-out here and there, every span between NSEC3'…

Restrict how?

> Include all Empty Non-Terminals in the NSEC3 chain.  

This would be a big change to signer implementations, and does not represent encoding current operational practice (at least to my knowledge).

> These changes permits DNSSEC code to be called RFC 5155 "fully" compliant - as no one (apparently) has taken time to implement this fully.

I'm not sure what you mean here.  Are you suggesting that if you haven't implemented a zone signer that generates a zone that mixes opt-out and non-opt-out NSEC3 RRs in a zone, you haven't fully implemented RFC 5155?

--
David Blacka                          <[email-masked]> 
Principal               Verisign Infrastructure Engineering

---

From: Alex Bligh <[email-masked]>
Date: Wed, 19 Dec 2012 09:15:51 +0000

> way to prove that there wasn't a delegation that should have blocked

The second sentence is correct, but that doesn't imply the first. It
just means with a wildcard under opt-out there is no way to prove a
wildcard should not have been blocked by a non-wildcard RR. That's
a calculated risk, like the calculated risk you take with OPTOUT
in general.

If your zone looks like

$origin example.com
	*.bar	IN 	MX 	test1.example2.com.
	foo.bar	IN	MX	test2.example2.com.
	baz	IN	MX	test3.example2.com.

then as far as I can see you risk the *.bar response being incorrectly
attributed to a query for foo.bar, but not to a query for baz.

-- 
Alex Bligh

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 19 Dec 2012 10:54:45 +0100

> way to prove that there wasn't a delegation that should have blocked

You are right, I gave it more thought. An example convinced me of the
incompatibility. Let me share it with the list:

There is no way to prove a wildcard should not have been blocked by a
opted-out empty non-terminal:

fqdn.       ;apex (has matching NSEC3, cpe for ent.fqdn and ns.ent.fqdn
*.fqdn.     ;wildcard (has matching NSEC3)
ent.fqdn.   ;empty non-terminal (no matching NSEC3)
ns.ent.fqdn ;unsigned delegation (no matching NSEC3)
foo.fqdn.   ;authoritative data (has matching NSEC3)

A query for <A, ent.fqdn.> could not provide a NSEC3 covering the source
of synthesis (*.fqdn.), because that name has a matching NSEC3. In other
words, ent.fqdn should have been wildcard expanded. But this is wrong,
because the name ent.fqdn. does exist.

> Implementations just uses the delegation state secure/insecure to make

But a signer implementation is able to detect whether the NSEC3 is
covering unsigned delegations or not. If not, it could set the Opt-Out
bit to 0 for that NSEC3. No need to select delegations to create a mixed
Opt-Out on/off chain.

> The only way to prevent zone walking in these zones is to lie in

That was not my point. If signers would be adding NSEC3s on all empty
non-terminals, we would also resolve the problem. Then only signer
implementations need code modification, instead of server and validator
implementations.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Dec 2012 09:48:32 -0500

First, thanks to those who posted to the list, I don't want to stem the tide now.  Keep thoughts coming.

But two things popped up in the responses so far that I can provide some clarifying comments on:

One, about "compliance"  - yes, I was saying that no implementations were fully because they didn't allow pick-and-choose opt-out.  But the comment id driven by some other thoughts.  The IETF claims "running code and rough consensus" but the running code today differs from the spec.  And as an operator I hear "the IETF wants operators to come in and help" but my observation is that when a protocol seems confusing and resulting in higher support costs, the spec still holds sway.  I was hoping that there'd be willingness to bring the spec into the reality space and not remain in the conceptual space.

Two, about the need or not for the wildcard NSEC3 in the proofs - that idea came from an off-list conversation with someone who derived the NSEC3 idea and document.  Unfortunately, that was private communication and not on the list, so I have to shuttle back and forth the ideas.  (This is why I want the discussion to remain on the open, transparent list.)

I'll wait for a few more comments before updating what I am thinking.   I want to encourage folks to pitch in as this is a working group effort.  It's not about anyone's individual perspectives or opinions.

---

From: Miek Gieben <[email-masked]>
Date: Thu, 20 Dec 2012 11:45:39 +0100

[ Quoting <[email-masked]> in "[dnsext] Clarifying a few points in..." ]
> First, thanks to those who posted to the list, I don't want to stem the tide now.  Keep thoughts coming.

I agree with Mark that "OPTOUT and wildcards are incompatible with each other".

Also Matthijs and I are working on getting
http://tools.ietf.org/html/draft-gieben-auth-denial-of-existence-dns-01
through the ISE stream. A reviewer asked if would could add text about opt-opt
(right now, we say nothing about it).

But of course that work does not exclude the need to file an errata against
5155.

 Regards,

-- 
    Miek Gieben                                               http://miek.nl

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 20 Dec 2012 14:05:34 +0000

> I agree with Mark that "OPTOUT and wildcards are incompatible with each other".

"incompatible" suggests to most people that using wildcards and NSEC3 Opt-Out causes something to break, which isn't true at all.

Instead, you just don't have the same security guarantees for wildcards that you do when not using Opt-Out, which is the basic tradeoff with Opt-Out.

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Dec 2012 14:55:01 +0000

Blacka, David <[email-masked]> wrote:
>
> "incompatible" suggests to most people that using wildcards and NSEC3
> Opt-Out causes something to break, which isn't true at all.
>
> Instead, you just don't have the same security guarantees for wildcards
> that you do when not using Opt-Out, which is the basic tradeoff with
> Opt-Out.

I understood the incompatibility to be that you can't have opt-out
delegations under a wildcard: they have to have a full complement of NSEC3
records. And if they have all their NSEC3 records then there is no loss of
security relative to other insecure delegations when there is no wildcard
interfering. And there can still be opt-out delegations in other parts of
the zone that do not have wildcards.

Tony.

---

From: "Blacka, David" <[email-masked]>
Date: Thu, 20 Dec 2012 22:16:51 +0000

> the zone that do not have wildcards.

This is why using the word "incompatible" is wrong.

You can put delegations (insecure and otherwise) and wildcards anywhere you want in a zone signed with NSEC3 Opt-Out, just like any other zone.  You just don't get the same security guarantees (meaning, an attacker could spoof a wildcard response into a NOERROR/NODATA or some other delegation.)

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Dec 2012 02:17:51 +0000

> You can put delegations (insecure and otherwise) and wildcards anywhere you want in a zone signed with NSEC3 Opt-Out, just like any other zone.  You just don't get the same security guarantees (mea…

If that is the case surely it is a serious bug. A resolver must be able to prove there is nothing but insecure delegations in an opt-out range, including no wildcards.

Tony.

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 21 Dec 2012 14:32:15 +0800

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: "dnsext mailing list" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>
Sent: Wednesday, December 19, 2012 10:48 PM
Subject: [dnsext] Clarifying a few points in Re: Update to RFC 5155. Maybe?

> 
> I'll wait for a few more comments before updating what I am thinking.   I want to encourage folks to pitch in as this >is a working group effort.  It's not about anyone's individual perspectives or opinions.
> 
>

which working group you will pitch in since the dnsext will soon close down?

It seems that we need to find a wg or creat a new wg to discuss the dnsext related things.

any idea?

Jiankang Yao

---

From: Miek Gieben <[email-masked]>
Date: Fri, 21 Dec 2012 08:32:04 +0100

[ Quoting <[email-masked]> in "Re: [dnsext] Clarifying a few point..." ]
> > You can put delegations (insecure and otherwise) and wildcards anywhere
> > you want in a zone signed with NSEC3 Opt-Out, just like any other zone. You
> > just don't get the same security guarantees (meaning, an attacker could spoof a
> > wildcard response into a NOERROR/NODATA or some other delegation.)
>
> If that is the case surely it is a serious bug. A resolver must be able to
> prove there is nothing but insecure delegations in an opt-out range, including
> no wildcards.

Why do you call this a bug? By allowing Opt-Out you forgo the security in that
range... Or do you call the Opt-Out feature in itself a bug?

 Regards,

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 21 Dec 2012 08:40:57 +0100

Tony,

On 12/21/2012 03:17 AM, Tony Finch wrote:
>>>> "incompatible" suggests to most people that using wildcards
>>>> and NSEC3 Opt-Out causes something to break, which isn't true
>>>> at all.
>>>> 
>>>> Instead, you just don't have the same security guarantees for
>>>> wildcards that you do when not using Opt-Out, which is the
>>>> basic tradeoff with Opt-Out.
>>> 
>>> I understood the incompatibility to be that you can't have
>>> opt-out delegations under a wildcard: they have to have a full
>>> complement of NSEC3 records. And if they have all their NSEC3
>>> records then there is no loss of security relative to other
>>> insecure delegations when there is no wildcard interfering. And
>>> there can still be opt-out delegations in other parts of the
>>> zone that do not have wildcards.
>> 
>> You can put delegations (insecure and otherwise) and wildcards
>> anywhere you want in a zone signed with NSEC3 Opt-Out, just like
>> any other zone.  You just don't get the same security guarantees
>> (meaning, an attacker could spoof a wildcard response into a
>> NOERROR/NODATA or some other delegation.)
> 
> If that is the case surely it is a serious bug. A resolver must be
> able to prove there is nothing but insecure delegations in an
> opt-out range, including no wildcards.

Putting insecure delegations and wildcards in a *zone* with NSEC3
Opt-out (what David is saying) is something different than a Opt-Out
NSEC3 that covers insecure delegations and wildcards (what you are
saying).

A zone with a wildcard configured somewhere, and with insecure
delegations (possibly a few labels deep, so there are some empty
non-terminals) is vulnerable to attacks where the insecure delegation
or one of the derived empty non-terminals is expanded to the wildcard.

Best regards,
  Matthijs

> 
> Tony. -- f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Dec 2012 14:50:53 +0000

> or one of the derived empty non-terminals is expanded to the wildcard.

I'm confused. Can you explain this in more detail?

I don't understand what additional security problem is caused by
wildcards. Can't you just avoid the problem by not having opt-out
NSEC3 records for the part of the zone affected by the wildcard?

I understand that an attacker can spoof insecure delegations within an
opt-out range.

Tony.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 21 Dec 2012 16:55:44 +0100

On 12/21/2012 03:50 PM, Tony Finch wrote:
>> non-terminals) is vulnerable to attacks where the insecure
>> delegation or one of the derived empty non-terminals is expanded
>> to the wildcard.
> 

Let's try with an example.

fqdn.        IN SOA and stuff.
*.fqdn.      IN A 1.3.3.7
ns.ent.fqdn. IN NS somewhere.

A query for <A, ent.fqdn.> can now be answered with

;; ANSWER SECTION
ent.fqdn.    IN A 1.3.3.7 (expanded from the wildcard)

;; AUTHORITY SECTION
h(x).fqdn. IN NSEC3 ... (covering ent.fqdn.)

h(x).fqdn. has its opt-out bit set, so the validator cannot assert or
deny the existence of ent.fqdn. This is what I think David means with
"wildcard response spoofed into a NOERROR/NODATA or some other delegation.

> NSEC3 records for the part of the zone affected by the wildcard?

The part of the zone affected is the opt-out range.

> I understand that an attacker can spoof insecure delegations within
> an opt-out range.

And it can spoof other stuff in the opt-out range.

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Dec 2012 16:04:30 +0000

> "wildcard response spoofed into a NOERROR/NODATA or some other delegation.

My understanding is that would be a bug in your signer. You can't have
opt-out NSEC3 records covering the part of a zone under a wildcard, which
is what was meant by "incompatible".

Tony.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 21 Dec 2012 17:52:35 +0100

On 12/21/2012 05:04 PM, Tony Finch wrote:
>> fqdn.        IN SOA and stuff. *.fqdn.      IN A 1.3.3.7 
>> ;; ANSWER SECTION ent.fqdn.    IN A 1.3.3.7 (expanded from the
>> wildcard)
>> 
>> ;; AUTHORITY SECTION h(x).fqdn. IN NSEC3 ... (covering
>> ent.fqdn.)
>> 
>> h(x).fqdn. has its opt-out bit set, so the validator cannot
>> assert or deny the existence of ent.fqdn. This is what I think
>> David means with "wildcard response spoofed into a NOERROR/NODATA
>> or some other delegation.
> 
> My understanding is that would be a bug in your signer. You can't
> have opt-out NSEC3 records covering the part of a zone under a
> wildcard, which is what was meant by "incompatible".

In this example, the wildcard is not covered by the opt-out NSEC3
record. The 'blocking' name is, because that is derived from an
insecure delegation.

Matthijs

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Dec 2012 17:22:42 +0000

> record. The 'blocking' name is, because that is derived from an

Yes, but the problem is that the wildcard is above the opt-out.

Tony.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 21 Dec 2012 10:55:11 -0800

On Fri, Dec 21, 2012 at 8:52 AM, Matthijs Mekking <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I am not sure what you mean by "wildcard is not covered by opt-out NSEC3
record" - Did you mean to say that *.fqdn does not have the opt-out bit set
? Are you using a mix of opt-out and no opt-out in this example ?

If the record returned in the Authority section has opt-out bit set, then
it is insecure (not explicitly mentioned in section 7.2.6 of 5155)

-mohan

Matthijs
> iQEcBAEBAgAGBQJQ1JPTAAoJEA8yVCPsQCW5CWEH/3RLKffWSdo7bZDsF4wDCcdb
> Nj4qN/QTTz0yo9R7tc1pbRW7wVJIkDMGYlhYfzkXHeY5ncpWis7GxRApvyAJt/tQ
> AunUD1et6W/Um03pf5MOE3xY+VYgwo7JGRbK1UtJvNjWEEE0CvB/8YdpqYprIbxM
> DCsT/qkbwowxzy7f37H2nu5Tt7S5yt0RMSkl7z5pWIX5C7CbmmghvnLrsWuZ57F2
> 9TQsj2BZPoZoHyKtsSXbrTGTb/PvISCYHV5P+/I6Tjy+pztuDd4Gok0gWxhtZCnI
> oJ2EIBJkrQ9nM2Sw0bO0xS1oCVVeF2LmNSAqR1HzMHBhSBlrRnKl+15X4EZzamQ=
> =aPtY

---

From: Edward Lewis <[email-masked]>
Date: Fri, 21 Dec 2012 14:23:39 -0500

> which working group you will pitch in since the dnsext will soon close down?

First, the process question.  The plan to handle the situation here is to submit an errata against RFC 5155.  Instead of just doing so outright, I wanted to get community feedback on what the right approach is.  This nugget of work is itself a "bug fix" against a completed RFC, something that is permanent - unlike WGs which my design are supposed to come and go.

The "bug" or "incompatibility" of wildcards and opt-out has been long known.  But I don't think it's a major problem.  On paper it looks like someone can spoof in a delegation that blocks a wildcard synthesis.  But in operations, the zones that would need to use opt-out are not zones that (generally) use wildcards.  You could, easily, but, in reality, no one does - outside of testing perhaps.

A malicious person could steal a credit card to pay for a stolen identity to register a name to host malware OR cache poison a bunch of servers via a Kaminsky-style attack to insert a name to host malware.  I'm not trained to think like a black-hat, but is seems to me that the former is a lot more common and promises more payoff.

As far as the notion that opt-out would be used in zone where the names are numbers - enum or reverse - opt-out isn't all that useful.  Besides the limited "guess space" in the number zones, operational use of enum has greater issues with confidentiality of the zones.  (I.e., bigger fish to fry.)

But ... What I'll repeat here is that I think that omitting ENTs from the NSEC3 chain is a optimization that gains little and costs a lot.  A lot in debugging time, a lot in spec writing time (because of having to expand the rules in the signer, server, and validator) and coding time.  Even if the spec and coding are sunk costs a this point, debugging and other maintenance costs lie in the future.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Dec 2012 15:46:27 -0500

The example is wrong...sorry, just getting aound to replying.

If ns.ent.fqdn. has an NS record and ent.fqdn. is empty, then the wildcard expansion won't happen if the latter is a QNAME.

The conflict between wild cards and opt-out is better illustrated by getting this example.  If a malicious agent wants to forge a response to "www.foo.fqdn. A" as a referral to ns666.servers.fqdn. and not "www.foo.fqdn. A 1.3.3.7" they can succeed with available opt-out records.  I.e., you can forge into existence a delegation in an opt-out range.

BUT ... that is no worse than not having DNSSEC.  That is the low-bar yardstick that used when evaluating tradeoffs.  While there are advantages in many places, if you deploy a wildcard and opt-out you are no better off with DNSSEC than without in the worst cases.

And DNSSEC can't ensure data gets to the recipient, it can only help the recipient decide to reject bad data.  On the Internet, you can never guarantee delivery of a signal, no matter what you do - even TCP only guarantees what arrives comes in order.

Ed

...Still thinking about this because I'm not sure of the optimization here bypassing ENTs in the NSEC3) is worth the hassle. 

On Dec 21, 2012, at 10:55, Matthijs Mekking wrote:

> iQEcBAEBAgAGBQJQ1IaAAAoJEA8yVCPsQCW5AdMH/RS8c5GZx7LLW9ccw2lGVsIn
> bAY1OGFIBmOZbcsORe6e/RdqgmAji3UyVyh7ADjE+xGZC5uawaqsjpxxfXwFbX7h
> lBjDf7NBPhZrzbeWtV8xEpke+cUYY7K+2qsOaEhfJvPaeBVn4C4xtLWAMGD8xv0q
> iEEgPjlESoDRSMJEoXp4czMqQdS/AuowuyCVc21I03/gDkMDTV31123ZlgQ1ph5M
> UdcF/0C++0tSmwVnoFMcFkHIu769s0L+EnoVReR/WCfemzQXCHyt+g4OdtrM56WN
> 8Pl95eyXQnQ4UpfaZ8Sn+dX68QQ4Q6UTmft/lIOevQN4wsiadot5PffaXjq3AyU=
> =1LMf

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 27 Dec 2012 23:22:45 +0100

On 12/27/2012 09:46 PM, Edward Lewis wrote:
> If ns.ent.fqdn. has an NS record and ent.fqdn. is empty, then the 
> wildcard expansion won't happen if the latter is a QNAME.

Won't happen, but it can be forged with available NSEC3 records.

> The conflict between wild cards and opt-out is better illustrated
> by getting this example.  If a malicious agent wants to forge a
> response to "www.foo.fqdn. A" as a referral to ns666.servers.fqdn.
> and not "www.foo.fqdn. A 1.3.3.7" they can succeed with available
> opt-out records.  I.e., you can forge into existence a delegation
> in an opt-out range.

If foo.fqdn. is an insecure delegation then yes (I would encourage you
to write down the example).

> BUT ... that is no worse than not having DNSSEC.  That is the
> low-bar yardstick that used when evaluating tradeoffs.  While there
> are advantages in many places, if you deploy a wildcard and opt-out
> you are no better off with DNSSEC than without in the worst cases.

I agree. I would even say: if you deploy opt-out you are no better off
with DNSSEC than without in the worst cases.

Best regards,
  Matthijs

> And DNSSEC can't ensure data gets to the recipient, it can only
> help the recipient decide to reject bad data.  On the Internet, you
> can never guarantee delivery of a signal, no matter what you do -
> even TCP only guarantees what arrives comes in order.
> 
> Ed
> 
> ...Still thinking about this because I'm not sure of the
> optimization here bypassing ENTs in the NSEC3) is worth the
> hassle.
> 
>>>>> A zone with a wildcard configured somewhere, and with 
>>>>> insecure delegations (possibly a few labels deep, so there 
>>>>> are some empty non-terminals) is vulnerable to attacks
>>>>> where the insecure delegation or one of the derived empty 
>>>>> non-terminals is expanded to the wildcard.
>>>> 
> ;; AUTHORITY SECTION h(x).fqdn. IN NSEC3 ... (covering ent.fqdn.)
> 
> h(x).fqdn. has its opt-out bit set, so the validator cannot assert 
> or deny the existence of ent.fqdn. This is what I think David
> means with "wildcard response spoofed into a NOERROR/NODATA or some
> other delegation.
> 
>>>> 
>>>> I don't understand what additional security problem is
>>>> caused by wildcards. Can't you just avoid the problem by not
>>>> having opt-out NSEC3 records for the part of the zone
>>>> affected by the wildcard?
> 
>>>> I understand that an attacker can spoof insecure delegations 
>>>> within an opt-out range.
> 
Edward Lewis

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Dec 2012 10:18:53 -0500

Looking over the discussion here and trying to figure out what should be done...and not wanting to let this hang too long.

If I had my choice, I'd try to simplify the protocol by signing the empty non-terminals, putting more restrictions on the chain, and so on.  I'd do this because as an operator, this would make the protocol easier to run, cheaper, simpler, and still get the objectives we want.

But in the spirit of an errata, I'll submit the words given to me from Roy (paragraphs shuffled as mentioned).  That's the process thing to do.