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

[Jari Arkko <[e-mail]>]

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
>> 
>