additions to dnssec-bis-updates-04.txt

[Roy Arends <roy@nominet.org.uk>]

As promised (though a little late) here are my quirks from the dallas-ietf 
presentation on DNSSEC-bis omissions:

One rant on DNSSEC-bis is that it groups empty-non-terminal response types 
as "name errors" instead of "no data errors" (section 3.1.3.2 of RFC 
4035). I think it was Rob Austein who explained during the WG session that 
the term "Name Error" used in DNSSEC-bis does not necessarily reflect 
"rcode=3 (name error)". In hindsight, this is purism, and does not create 
any holes in the validation logic. This is not all that important, so my 
suggestion here is to remove the following part in dnssec-bis-updates:

2.2.  Empty Non-Terminal Proofs

   To be written, based on Roy Arends' May 11th message to namedroppers.

   The editors are trying to figure out whether what's really required
   here is a discussion of the relationship between DNS RCODEs and
   DNSSECbis.

Other points of my presentation in Dallas were: 

(1) ancestor versus parent terminology

I'd suggest avoiding 'parent-side' terminology in favor of 'ancestor' for 
NSEC Origin checks. For every existing name (except for the empty 
label/root), there exists a spanning NSEC in an ancestor zone. Not just at 
the parent zone. So the following rule for the type-bit-map must be true 
for proof of absence of name check when NSEC ownername is an ancestor of 
the QNAME: (NOT DNAME) AND ((NOT NS) OR SOA). My guess is that you wanted 
to state this in section 2.1 of the update document, but that needs to 
rewritten. This is somewhat a purity issue, since the validator can't 
distinguish parent from grandparent or further ancestors.

(2) gaping hole:

validation in rfc4035 for unsigned delegation needs an NSEC for proof of 
absence of DS records. Section 5.2 of RFC 4035 states that the validator 
needs to check for the absence of DS type and absence of SOA type, but 
fails to mention to check for the presence of NS type. If this is not 
checked, spoofed unsigned delegations can be used to claim an existing 
signed record is not signed.

(3) spoofing cname into nonexistence.

If response is of type nodata: check NSEC for absence of CNAME type, 
otherwise a claim for nodata at name X/type Y might be a spoof, since the 
type might exist at the canonical name for X.

(4) expanding wildcards/wildcard no data response

Both response types need a proof that the wildcard is at the closest 
encloser. The closest encloser can be determined by comparing QNAME to 
both ownername and nxtdname of the NSEC and take the nearest common 
ancestor. Every NSEC in a response MUST have the same closest encloser 
(this is fact, not a requirement). i.e. validator must check this way that 
there is no closer wildcard match.

Hope this helps,

Roy Arends
Nominet UK

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>