As part of my secdir review of draft-ietf-dnsop-maintain-ds-03 (https://www.ietf.org/mail-archive/web/secdir/current/msg06685.html), I noticed that it indicated that the status of RFC 7344 should be changed to Proposed Standard, and reviewed RFC 7344 at the same time. I repeat those comments here to have them entered into the appropriate archive; I do not think that they merit blocking the status change. -Ben %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 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. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%