[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-cds-consistency

[Peter Thomassen <[e-mail]>]

Hi Ondřej,

On 7/11/25 17:35, Peter Thomassen wrote:
>> The appendix A.1. describes an impossible failure scenario, considering that Section 6.2 of RFC 7344 says that:
>>
>>  >  The Parental Agent MUST ensure that previous versions of the CDS/
>>  >  CDNSKEY RRset do not overwrite more recent versions.
>>
>> With this MUST in place, the scenario described in A.1. just cannot happen. It is not a big deal, but seeing it written like this is implying that this risk was not considered when writing RFC 7344, which is not the case.
> 
> You are correct. That failure scenario only occurs when not tracking "previous" vs. "new" CDS/CDNSKEY RRset. And I've just checked: there's at least one registry that makes a reasonable attempt at this sort of tracking.
> 
> I thus agree with you that Appendix A.1 can then be removed. I'll note that down for the next update after the submission window opens again.
[...]
> The cross-nameserver consistency checks from this can catch such replication issues (but also things beyond, such as multi-signer misalignment). With consistency checks in place, I'm thus wondering whether inception/serial state tracking on the parent side adds much value, or can be relaxed from MUST to SHOULD or MAY. What do you think?

I thought about this again, and realized that there's nothing to change in RFC 7344, because the consistency checks actually fulfill the MUST of RFC 7344 Section 6.2. It's just another way of doing it, and the particular way of doing it is not covered by the MUST: the method proposed there is specifically MAY.

I thus retract my proposal update this aspect of RFC 7344.

As for removing Appendix A.1, I think it's worth pointing out that this draft is one way of handling this problem, with RFC 7344's requirement in mind. I'm thus proposing to change the language as follows:

OLD
    be deployed in an alternating fashion.  The zone maintainer, having
    detected that the DS deployment was successful, may then confidently
    remove the old DNSKEY from the zone, only to find out later that the
    DS RRset has been turned back, breaking the delegation's DNSSEC chain
    of trust.

    Checking for consistency minimizes this risk.  In case the parent
    reports consistency errors downstream, it can also help detect the
    replication issue on the child side.

NEW
    be deployed in an alternating fashion and without the awareness of
    the zone maintainer, who may then inadvertently break the chain of
    trust by prematurely removing a DNSKEY still referenced by a (stale)
    CDS/CDNSKEY RRset.

    While foreseen in [RFC7344] Section 6.2, the solution suggested there
    requires parents to keep state on CDS/CDNSKEY RRsets.  This document
    achieves the same without this burden, and in case the parent reports
    consistency errors downstream, can also help detection of the child-
    side replication issue by the operator.

Please let me know in case that doesn't work for you, or if you have any other thoughts/suggestions.

I'm planning to upload the a revision at the end of the week.

Best,
Peter