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: