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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%