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

[Olafur Gudmundsson <[e-mail]>]

On Jun 10, 2014, at 4:24 PM, Brian E Carpenter <[e-mail]> wrote:

> 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/.
> 
Sorry Brian, 
I fixed this in the XML document will be in the next version or the version we send to the RFC editor
which ever comes first. 

	Olafur

> 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 <[e-mail]> wrote:
>> 
>>> Thanks!
>>> 
>>> On 10 Jun 2014, at 17:57, Olafur Gudmundsson <[e-mail]> wrote:
>>> 
>>>> Jari, 
>>>> we will push one out today 
>>>> 
>>>> 	Olafur
>>>> 
>>>> 
>>>> 	
>>>> On Jun 10, 2014, at 8:30 AM, Jari Arkko <[e-mail]> 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 <[e-mail]> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/gen-art
>> 
>>