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

[Warren Kumari <[e-mail]>]

On Thursday, June 5, 2014, Brian E Carpenter <[e-mail]>
wrote:

> Totally bizarre. I found them in the trash on my gmail account,
> but no trace of them in my local Gen-ART inbox.
>
> Presumably there was some finger trouble. I apologise,


Nah, no worries, mate..

W



> and please
> watch this space for a corrected review.
>
> Regards
>    Brian
>
> On 06/06/2014 13:37, Warren Kumari wrote:
> > 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]
> <javascript:;>> 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:;>
> >> <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.
> >>> Sh