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 >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
