ietf
[Top] [All Lists]

Re: [dnsext] Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18

2012-07-31 11:56:37

On Jul 30, 2012, at 1:18 PM, Richard L. Barnes wrote:


MAJOR:

4.1.  
It's not clear what the threat model is that this section is
designed to address.  If the zone operator is malicious, then it can
simulate the necessary zone cut and still prove the non-existence of
records in the child zone.

The problem here is not a malicious parent operator, but "an NSEC or
NSEC3 RR from an ancestor zone".  In the original specification, an
attacker could use such an RR to prove the non-existence of some name
in a subordinate zone.  That was the problem.  (Remember, in DNS there
is a good chance that you are not talking to an authoritative server.)
If you have suggestions on ways to make that clearer, it'd be welcome.
The editors tried to come up with compact examples that would be
anything other than mystifying, and were unsuccessful.  

I guess I still don't understand this.  Aren't ancestors the only people that 
can generate a valid, signed NSEC or NSEC3 RR?  So if there were a bad 
NSEC[3], wouldn't it be the ancestor's fault?

This isn't about "bad NSEC[3]" RRs.  It is about an attacker (think 
"man-in-the-middle") using the valid, completely correct NSEC[3] RR from the 
parent zone in an inappropriate context.

If the provisioning is *intentional*, then as I noted before, then there's 
not really anything to be done, since the ancestor can provide whatever 
information he wants for the child zones (as above).  So are you worried 
about *inadvertent* provisioning of these bad records?  

Again, the record isn't "bad", but being used in the wrong context (either via 
a software bug or on purpose as an attack).  This section isn't about malicious 
zone operators at all.

I still don't have any great ideas for how to change the text to make this more 
clear, however.

--
David Blacka                          <davidb(_at_)verisign(_dot_)com> 
Principal               Verisign Infrastructure Engineering





<Prev in Thread] Current Thread [Next in Thread>