OK, the -14 version is fine IMHO. (Jari, a few of my points were explained by email so did not result in text changes.)
Just one thing - you don't need to acknowledge my review, but if you do, please s/Carpender/Carpenter/. Regards Brian On 11/06/2014 05:14, Olafur Gudmundsson wrote: > Posted > you welcome > > Olafur > > On Jun 10, 2014, at 1:07 PM, Jari Arkko <jari.ar...@ericsson.com> wrote: > >> Thanks! >> >> On 10 Jun 2014, at 17:57, Olafur Gudmundsson <o...@ogud.com> wrote: >> >>> Jari, >>> we will push one out today >>> >>> Olafur >>> >>> >>> >>> On Jun 10, 2014, at 8:30 AM, Jari Arkko <jari.ar...@ericsson.com> wrote: >>> >>>> Thanks for the review, Brian, and thank you Warren and Olafur for answers. >>>> I do agree with the remaining issues as listed by Brian below; can I >>>> expect a new draft revision to address these? >>>> >>>> Jari >>>> >>>> On 06 Jun 2014, at 05:12, Brian E Carpenter <brian.e.carpen...@gmail.com> >>>> 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 on version -13. The authors responded >>>>> with helpful explanations, and I understand that they plan some >>>>> corresponding changes before publication. >>>>> >>>>> 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 >>>>> Gen-art@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
