Early Review of draft-ietf-dnsop-cds-consistency-04
review-ietf-dnsop-cds-consistency-04-secdir-early-kaufman-2023-11-08-00

Reviewer: Charlie Kaufman
Review result: Has nits

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.

This document prescribes a change to the automated procedure for updating
DNSSEC delegation trust maintenance as described in RFC7344 and RFC7477. The
existing procedure calls for updates to be automated in the parent zone if
signed instructions exist in the child zone *ON ANY* authoritative name server,
while the new procedure calls for those updates to be done only when consistent
signed instructions exist *ON ALL* authoritative name servers (or at least on
the functioning ones).

The intent of this change is to reduce the probability changes will occur in
the parent zone before they take place on all child zones which could lead to
valid data being rejected if the condition persists or if updates are made
incorrectly. There is particular concern in the case where there are multiple
independent zone operators and an error (or even a malicious change) by one
makes the zone unavailable from the others. The cost is that this may delay the
automated changes sufficiently that the zone operator will have to revert to a
manual interaction with the parent zone to get the changes made.

It is hard to judge how important this is without understanding how robust DNS
is in the event that multiple providers of a single zone accidentally or
maliciously diverge, and how likely administrative errors are. I'm suspicious
as to the practicality of this design in solving the problem. If these zone
updates are automatically propagated to all peer zone providers, then this
change will not prevent errors from propagating to the parent zone. If they do
not, this requirement may create an undue burden on those maintaining zones to
manually propagate the changes to their peer providers. But this is not my
field, so I have to assume the designers know what they are doing.

NIT: Section 2.2: CYSNC -> CSYNC