Re: additions to dnssec-bis-updates-04.txt

[Sam Weiler <weiler@tislabs.com>]

[Sorry for the out-of-order messages.  I orginally sent these three 
messages last night, which is why you've already seen a couple of 
replies.  Hopefully the mailserver brokenness that led to them 
bouncing has been fixed.]

On Tue, 19 Dec 2006, Roy Arends wrote:

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

Thanks for sending these.  I've incorporated most of them in the next revision. 
Comments in-line below:

> ... my
> suggestion here is to remove the following part in dnssec-bis-updates:
>
> 2.2.  Empty Non-Terminal Proofs

Done.

> (1) ancestor versus parent terminology
>
> I'd suggest avoiding 'parent-side' terminology in favor of 'ancestor' for

Based on the on-list discussion: Done.

> (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.

Perhaps I'm confused, but I'm not seeing the problem here.  Could you create an 
example for me?

> (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.

This does seem like a real deficiency.  I added a section on CNAMEs. The text 
is imperfect, but it's there.

> (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.

I'm vaguely remembering some discussion of why we didn't need anything more and 
why 4035's text was, in fact, sufficient.  Since I don't fully recall the 
details, I'd like someone else to confirm this before we add it, and preferably 
to write the text on it.  Can we have some more discussion on this item?

> Hope this helps,

Absolutely.  Thank you for the input.

-- Sam


--
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/>