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 <[email protected]> Principal Verisign Infrastructure Engineering
