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

From: Roy Arends <[email-masked]>
Date: Mon, 5 Mar 2007 08:13:45 +0100

Sam Weiler <[email-masked]> wrote on 03/04/2007 10:17:05 PM:

> 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:
> 
> > (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?

Given the records:

www.example.com A 192.0.2.16
www.example.com NSEC    A NSEC RRSIG

I could create (spoof) a response:

www.example.com NS hacker.example.net
www.example.com NSEC    A NSEC RRSIG

According to the rules in 5.2, the validator needs to check for the 
absence of DS and SOA in this NSEC record. This check passes. Obviously, 
the validator needs to check for presence of the NS bit, but the section 
does not mention that.
 
> > (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?

Here is an example:

zone:

         example.com NSEC *.example.com
       *.example.com A    192.0.2.1
     bar.example.com NSEC *.bar.example.com 
   *.bar.example.com A    192.0.2.2
alfa.bar.example.com NSEC gamma.bar.example.com

Query:

 foo.bar.example.com A

Spoofed response:

 foo.bar.example.com A 192.0.2.1 
 foo.bar.example.com RRSIG (labelcnt=2)
alfa.bar.example.com NSEC gamma.bar.example.com

Real response:

 foo.bar.example.com A 192.0.2.2 
 foo.bar.example.com RRSIG (labelcnt=3)
alfa.bar.example.com NSEC gamma.bar.example.com

Roy

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

---

From: Sam Weiler <[email-masked]>
Date: Mon, 5 Mar 2007 14:32:15 -0500 (EST)

[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

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

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

> otherwise a claim for nodata at name X/type Y might be a spoof, since the

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

> (this is fact, not a requirement). i.e. validator must check this way that

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