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

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

Sam Weiler <weiler@tislabs.com> 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 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/>