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