Hi, I'm the shepherd for this draft. Thanks for the review. Some follow-up inline. On Fri, May 25, 2012 at 05:02:28PM -0400, 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. > 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. Thanks again for the review. Best regards, A -- Andrew Sullivan ajs@xxxxxxxxxxxxxxxxxx