(sorry, retransmission with corrected address) 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-dnsop-delegation-trust-maintainance-13.txt Reviewer: Brian Carpenter Review Date: 2014-05-20 IETF LC End Date: 2014-05-26 IESG Telechat date: Summary: Almost ready -------- Minor issues: ------------- > 1. Introduction ... > Any manual process is susceptible to mistakes and / or errors. Also susceptible to social engineering or malicious leaks, I think. There's a fairly strong security argument for getting humans out of the process. > 3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions ... > it is up to the consumer of the records to > translate that into the appropriate add/delete operations in the > provisioning systems Not clear here whether this is expected to be an automated or manual process. > If no CDS / CDNSKEY RRset is present in child, > this means that no change is needed. Not clear here how we ensure that update is performed exactly once. See below. > 4. Automating DS Maintenance With CDS / CDNSKEY records > > CDS / CDNSKEY resource records are intended to be "consumed" by > delegation trust maintainers. The use of CDS / CDNSKEY is optional. I think that could be OPTIONAL. > The child SHOULD publish both CDS and CDNSKEY resource records. Given the previous sentence, I think this needs to be If the child publishes either the CDS or the CDNSKEY resource record, it SHOULD publish both. > 4.1. CDS / CDNSKEY Processing Rules ... > If there are no CDS / CDNSKEY RRset in the child, this signals that > no change should be made to the current DS set. This means that, > once the child and parent are in sync, the Child DNS Operator MAY > remove all CDS and CDNSKEY resource records from the zone. Does that mean the the child MAY/SHOULD/MUST monitor what the parent is publishing in order to automate this process? If not, you are calling for a manual operation. (The text in section 5 is repetitious, by the way, but still doesn't clarify this.) > If any these conditions fail the CDS / CDNSKEY resource record MUST > be ignored. Silently? Should this be logged? Any DOS potential here? Should use of these RRs be rate-limited in both child and parent to avoid any DOS risk? > 6. Parent Side CDS / CDNSKEY Consumption I don't think you specify what the parent should do if it receives both a CDS and a CDNSKEY and they are inconsistent (in violation of section 4). Yes, it's a corner case but Murphy's law always applies. > 9. Security Considerations ... > While it may be tempting, this SHOULD NOT be used for initial > enrollment of keys since there is no way to ensure that the initial > key is the correct one. If is used, strict rules for inclusion of > keys such as hold down times, challenge data inclusion or similar, > ought to be used, along with some kind of challenge mechanism. Shouldn't that "ought to" be MUST? Weak protection against a bogus initial key really seems like a "Crypto Won't Save You Either" poster child. Nits: ----- (from the shepherd's write-up) "The document references the document draft-ietf-dnsop-dnssec-key-timing, which had been approved for publication but never followed through on, and is shown to be expired." This is an informational reference and could probably be deleted without harm. "Additionally, the document references RFC2119 key word "NOT RECOMMENDED" without referencing it. " That is a well known bug in RFC 2119 itself. The citation can be fixed as per http://www.rfc-editor.org/errata_search.php?eid=499