Re: [dnsext] Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18

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@anvilwalrusden.com
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext