Posted
you welcome
Olafur
On Jun 10, 2014, at 1:07 PM, Jari Arkko <[email protected]> wrote:
> Thanks!
>
> On 10 Jun 2014, at 17:57, Olafur Gudmundsson <[email protected]> wrote:
>
>> Jari,
>> we will push one out today
>>
>> Olafur
>>
>>
>>
>> On Jun 10, 2014, at 8:30 AM, Jari Arkko <[email protected]> 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 <[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 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/gen-art
>>>
>>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
