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