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:

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.

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.