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

[Warren Kumari <[e-mail]>]

I replied 6 days ago, Olafur followed up 3 days ago.

Maybe you have us kill-filled? :-)

W

On Thursday, June 5, 2014, Warren Kumari <[e-mail]> wrote:

> Brian, can you please re-check?
>
> Olafur and I both replied -- I've just gotten off a plane and so cannot
> easily resend, will do tomorrow if you didn't get our mails...
>
> W
>
> On Thursday, June 5, 2014, Brian E Carpenter <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[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. I have seen no response.
>>
>> 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
>>
>