Re: [Gen-art] Gen-ART telechat review of draft-ietf-dnsop-delegation-trust-maintainance-13.txt (updated)

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.arkko@ericsson.com> wrote:
> 
>> Thanks!
>>
>> On 10 Jun 2014, at 17:57, Olafur Gudmundsson <ogud@ogud.com> wrote:
>>
>>> Jari, 
>>> we will push one out today 
>>>
>>> 	Olafur
>>>
>>>
>>> 	
>>> On Jun 10, 2014, at 8:30 AM, Jari Arkko <jari.arkko@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.carpenter@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
> 
> 