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

["Richard L. Barnes" <[e-mail]>]

Forgot to copy gen-art.

Begin forwarded message:

> From: "Richard L. Barnes" <[e-mail]>
> Subject: Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18
> Date: May 25, 2012 5:02:28 PM EDT
> To: IESG <[e-mail]>, [e-mail]
> Cc: [e-mail]
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-dnsext-dnssec-bis-updates-18
> Reviewer: Richard Barnes
> Review Date: May-25-2012
> IETF LC End Date: Not known
> IESG Telechat date: Jan-05-2012
> 
> Summary: Almost ready, couple of questions
> 
> 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.  
> 
> 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.
> 
> 
>