Last Call Review of draft-ietf-dnsop-maintain-ds-03
review-ietf-dnsop-maintain-ds-03-secdir-lc-kaduk-2016-07-14-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I believe this document is ready with nits.  This document also proposes
to move RFC 7344 from Informational to Standards-Track, so I have also
reviewed RFC 7344; I have some comments about RFC 7344, but I do not
believe that they merit blocking the status change.

RFC 7344 specifies the CDS and CDNSKEY DNS records that are used to
automate DNSSEC key updates (as in double-DS key rollover) by
communicating keying information from child zone to parent zone so the
parent can include the updated DS records; this document extends those
interfaces for use in removing DNSSEC from a child domain and, to some
extent, the initial provisioning of DNSSEC for the child domain.

The security considerations sections (of both documents) seem to
accurately describe the potential issues with these interfaces, including
the inherent loss of security in removing DNSSEC from a zone (but does
describe scenarios in which it is the least-bad option).  The treatment of
using the CDS/CDNSKEY records for initial provisioning has a less complete
protocol specified than the treatment of deletion, but still provides some
benefit.

In Section 3, first paragraph, it is unclear to me why the period that DNS
answers for the child could be forged starts when the child publishes the
CDS record -- DNS responses can always be forged in the absence of DNSSEC.

The text in Section 3.1 seems to allow an authenticated trigger for the
parent to poll, but does not indicate that the RRset retrieved by the
parent should be presented in the UI for validation, leaving a potential
window in which the CDS record could be forged and the wrong key used for
the new DS record.

Section 3.4 seems unuseful, or at least under-specified, to me -- if a
requestor can create (or spoof) a CDS record and cause the parent to send
a challenge, the attacker already has the capability to insert a record
and could reply to the challenge.  So, presumably the CDS record is not
the trigger for the challenge, but the text could make it clear.  (Also,
what channel is used for the parent to instruct the requestor to insert
the sigil record; presumably this is some authenticated UI which is also
how the requestor is starting the enrollment process.)

Section 4 (antepenultimate paragraph) makes the claim that this document
does not define the DS Digest algorithm 0, but this document does make a
normative requirement for when 0 should be used in a field that is
specified to hold DS Digest algorithms, so I think it is reasonable to
update the registry to note that fact.  (While it probably does not make
sense for any software to look at the digest algorithm before checking the
security algorithm, is that really something we want to rule out?)

Section 5 suggests that a parent zone could email a child zone contact
address of pending changes; an automated system that sends email without
rate-limiting controls runs the risk of being a DoS vector by filling the
recipient's inbox.  Maybe put a parenthetical "with rate limiting" as was
done for the polling triggers in RFC 7344?

Finally, there are a couple places where some mandatory action is
contingent on "other acceptance tests" or similar underspecified
application- or registrar-specific checks.  This basically undermines the
mandatory nature of the requirement due to the vagueness of additional
checks, but I am not sure that any change is needed to the text of the
document; I just wanted to mention the apparent disparity.

Editorial notes appear after the comments on RFC 7344.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Additional comments on RFC 7344
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I doubt that these comments will be remembered by the time a 7344bis comes
around, but will put them out there anyway.

Section 3 (of RFC 7344) specifies that the absence of a CDS/CDNSKEY record
in the child means that no changes are to be made to the DS records in the
parent.  An attacker that is able to prevent the parent zone's resolvers
from seeing the CDS/CDNSKEY records would thus be able to prevent the DS
update, a denial of service.  One would hope that the DNSSEC-enabled
parent zone would use a validating resolver when it queries the child
zone, but it is probably worth mentioning explicitly, and the behavior
in the error case when the query fails.

It would have been nice if Section 4 had given a fuller description of
what it means for the [CDS and CDNSKEY] RRsets to "match in content" when
it restricts what the child can publish.

Likewise, Section 4.1 could have given more detail as to whether only the
parent SHOULD log the error, or if a child might be doing that validation
and logging as well.

In Section 6.1, where the delegation UI is being used to trigger
CDS/CDNSKEY processing and key confirmation, it might be worth mentioning
that that UI should be over a secure channel.  (It should be anyway,
but...)

The security considerations text about "this mechanism SHOULD NOT be used
to bypass intermediaries that might cache information" feels a bit like
"hope and pray that nothing goes wrong", since it may not always be clear
to all parties exactly what intermediates might be involved for any given
child/parent.  More concrete guidance about which parties must do what
checking before enabling CDS/CDNSKEY service for which users could be
useful.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Editorial notes for draft-ietf-dnsop-maintain-ds-03
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

In general, there are several places where the style and tone of the
document are somewhat informal, which is a bit unexpected for me in a
Standards-Track document, though not necessarily wrong.  Things like
Section 1.1, "The big issue", Section 2's "In many people's minds, [...]
[t]his document argues [...]", Section 2's "In many people's minds, [...]
this document argues[...]", etc..  The part in Section 1.1 where "[t]his
document makes the assumption that there are reasonable policies that can
be applied and will allow automation of trust introduction" might also be
improved, perhaps as "This document shows that there are reasonable
policies that allow for automation of trust introduction in some cases".

In Section 1.2, could we get some additional punctuation around the list
indices to help set them off from the associated text?  There also seems
to be strong overlap between some of them, like 1/3 and 1/4.  (1) also
doesn't seem quite grammatical; exactly what is the alternative to proper
rollover?  Should (4) say "the child zone" instead of just "the zone"?

Section 1.3, first paragraph, last word, spell as "digest".

Also Section 1.3, maybe reference Appendix A of RFC 7344 for the RRR
background?

In Section 2.1, is the semantics of publishing a CDS RRset interpreted to
mean that, or *defined* to mean that?  (Is the text in quotes actually a
quotation from something else, or the newly-minted definition?)

Still in Section 2.1, s/Reset/RRset/

In section 4, do we need list indices for CDS and CDNSKEY in the figure?

The word "Users" is used only once in the document, in Section 5.  Would
it be better to use a more specific term ("domain owners", perhaps?) since
"users" is a bit underspecified here?


-Ben