Hey Andrew,
Thanks for following up, and sorry for the lag. Thank goodness for IETF
meetings giving us time to process email :)
Couple of responses inline.
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?
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?
5.10.
I find the recommendation of the "Accept Any Success" policy
troubling. It deals very poorly with compromise (and other
roll-over scenarios): Suppose there are two trust anchors, one for
example.com and one for child.example.com. If the private key
corresponding to the TA for child.example.com is compromised, but
the validator continues to trust it, this negates the benefit
provided by the parent (example.com) facilitating a rollover.
Suggest an alternative policy, "Highest Signer": Out of the set of
keys configured as TAs, the validator only uses a key as a TA (for
purposes of validation) if there does not exist a DNSSEC path from
it to any other TA. This policy seems like more work to enforce
(because you have to do more backward chaining), but ISTM that the
validator should have the necessary DNSSEC records anyway, so it's
just a matter a couple of quick checks.
First, the Working Group debated this matter at considerable length,
several times. The Accept Any Success policy provides greater
robustness in the face of configuration errors, and is more likely to
lead to continued resolution. We believe, based on experience so far,
that such configuration errors are vastly more likely than key
compromise. If we are to reopen this, we will need to go back to the
WG again.
Note that Appendix C does discuss other options and 5.10 explicitly
suggests that this be configurable; but, because the biggest problem
we have is resolution failure in the face of mucked up configurations,
the consensus was that Accept Any Success was the best default. That
could, of course, change in future, at which time an update to the
document would be advisable.
The suggestion for "Highest Signer" is interesting but has never to my
knowledge been previously mooted in relation to this draft. I
therefore think that including it in particular would require some
review. I don't know of any implementation that currently uses that
approach, either (but since there are vast gaps in my knowledge even
of what's on my desk, it wouldn't surprise me to learn that there were
some). Do you know of any? If not, it seems to me that it would be a
good idea to have some fielded experience with the approach before
recommending it as default. It's an intriguing idea, however, and
seems to me to be worth pursuing. I'm just not sure it should be in
this draft. I personally think it would be premature to recommend it
as default, but if you take your position very firmly I am prepared to
take the question up with the Working Group.
Ok, I can understand these considerations. Typical usability/security
trade-off.
As per the normal security MO, if you're going to recommend an approach with
known security weaknesses, then you need to document them. I think it would be
helpful to note how this approach can lead to problems, e.g., by causing you to
miss a roll-over of a compromised key. The current text seems insufficient,
especially because it's relegated to an appendix. Suggested text at the end of
Section 5.10:
NEW:
"
This policy minimizes the likelihood that configuration errors in servers or
resolvers will result in validation failures. However, by the same token, a
resolver following this policy is vulnerable to a broader set of attacks than
one following a more restrictive policy. For example, if the resolver has TAs
for a parent domain and a child of that parent, and the child's key is
compromised, then the resolver will continue to validate responses signed under
the compromised key even if a new key for the child is published in a DS record
signed by the parent.
"
May also be helpful to say something like "as we get more experience with
validation, we may find that it's OK to be more restrictive".
If you're willing to, it might be helpful to document the "Highest signer"
approach. If so, let me know and I can provide text.
Thanks,
--Richard