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

[Warren Kumari <[e-mail]>]

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