Telechat Review of draft-ietf-dnsop-delegation-trust-maintainance-13
review-ietf-dnsop-delegation-trust-maintainance-13-genart-telechat-carpenter-2014-06-06-00

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