I replied 6 days ago, Olafur followed up 3 days ago. Maybe you have us kill-filled? :-)
W On Thursday, June 5, 2014, Warren Kumari <[email protected]> wrote: > Brian, can you please re-check? > > Olafur and I both replied -- I've just gotten off a plane and so cannot > easily resend, will do tomorrow if you didn't get our mails... > > W > > On Thursday, June 5, 2014, Brian E Carpenter <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> 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 wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-dnsop-delegation-trust-maintainance-13.txt >> Reviewer: Brian Carpenter >> Review Date: 2014-06-06 >> IETF LC End Date: 2014-05-26 >> IESG Telechat date: 2014-06-12 >> >> Summary: Almost ready >> -------- >> >> Comment: >> -------- >> >> These are my Last Call comments. I have seen no response. >> >> 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 >> >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
