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