[DNSOP] Re: SECDIR IETF LC review of draft-ietf-dnsop-ds-automation-05

[Peter Thomassen <[e-mail]>]

Hi Donald,

Thank you for your review! Please see inline.

On 5/11/26 01:18, Donald Eastlake wrote:
> this is much more of an operations BCP than a security BCP.
[...]
> # Security
> 
> I believe there are security threats addressed by this document but it seems to mostly focus on potential operational problems of "inconsistency" and "unexpected and confusing" behavior. It might be useful to give some examples of security problems that can be caused by ignoring these recommendations or, if you are sure, to state that there are none (which I doubt). How do these recommendations interact with the compromise of various of the parties in the RRR model or with an on-path attacker?

draft-ietf-dnsop-cds-consistency (which is about to be published) is normatively referenced by the draft at hand, and contains an entire appendix [1] on what can go wrong if consistency requirements are not honored.

The current document is supposed to give operational guidance without re-describing everything that has been said in other documents. It would otherwise be very long. :-) Folks from the WG have specifically pushed to keep this shorter, and to not repeat too many considerations. As an example of the WG discussion, see [2] (search for "RFC 6781" therein).

While I'm of course open to adjusting text, I don't see how to do it without challenging the WP's consensus. As you also said "this is much more of an operations BCP than a security BCP" and nobody has brought up the concern before, I'm doing nothing about this for the moment, unless I hear objections.

[1]: https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-11.html#name-failure-scenarios-due-to-in
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/5jVEyldeIuPOFu917_2A9V2jnuE/

> # Minor
> 
> Section 4.2.2, last paragraph: Wouldn't there be some advantage to lowering the TTL of the old DS RRset if you did so early enough before the DS update?

No. An old revision [3] contained the following text (in an appendix on "Approaches not pursued", which the WG later decided to drop):

OLD
    It is not necessary to equally reduce the old DS RRset's TTL before
    applying a change.  If this were done, the rollover itself would have
    to be delayed [for this extra step] without any apparent benefit.  With the goal of
    enabling timely withdrawal of a botched DS RRset, it is not equally
    important for the previous (functional) DS RRset to be abandoned very
    quickly.  In fact, not reducing the old DS TTL has the advantage of
    providing some resiliency against a botched DS update, as clients
    would continue to use the previous DS RRset according to its normal
    TTL, and the broken RRset could be withdrawn without some of them
    ever seeing it.  Wrong DS RRsets will then only gradually impact
    clients, minimizing impact overall.

[3]: https://www.ietf.org/archive/id/draft-ietf-dnsop-ds-automation-01.html#name-approaches-not-pursued

> Section 4.2.3, last paragraph: I found this paragraph a little hard to understand. What exactly does "Child DNS operators are held responsible for publishing contradictory information" mean? Isn't it just that when a Child DNS operator publishes contradictory information, the parent rejects it?

It's supposed to mean that Child DNS operators have the responsibility to publish consistent information across auths: if they don't, the parent won't second-guess what the intention could have been; it simply won't work.

I agree that this sentence is not very clear, and applied a fix. In doing so, I've also swapped another sentence around for flow:

OLD
    If both RRsets are published, Parents are expected to verify
    consistency between them by verifying that they refer to the same set
    of keys [I-D.ietf-dnsop-cds-consistency].  The CDS digest field need
    only be verified when the hash digest algorithm is designated as
    "MUST" in the "Implement for DNSSEC Delegation" column of the "Digest
    Algorithms" registry [DS-IANA], and may otherwise be ignored when the
    digest type is unsupported.

    By rejecting the DS update if RRsets are found to be inconsistent,
    Child DNS operators are held responsible when publishing
    contradictory information.  Note that this does not imply a
    restriction to the hash digest types found in the CDS RRset: if no
    inconsistencies are found, the parent can publish DS records with
    whatever digest type(s) it prefers.

NEW
    If both RRsets are published, Parents are expected to verify
    consistency between them by verifying that they refer to the same set
    of keys [I-D.ietf-dnsop-cds-consistency].  By not second-guessing
    inconsistencies (such as by RRset recency) and instead rejecting
    them, responsibility to clearly express each update request is placed
    on the Child DNS operator.

    The CDS digest field need only be verified when the hash digest
    algorithm is designated as "MUST" in the "Implement for DNSSEC
    Delegation" column of the "Digest Algorithms" registry [DS-IANA], and
    may otherwise be ignored when the digest type is unsupported.  Note
    that this does not imply a restriction to the DS hash digest types:
    if no inconsistencies are found, the parent can publish DS records
    with whatever digest type(s) it prefers.

> Also, doesn't a parent always have the power to publishes whatever DS or other records it wants?

Yes, of course.

> Section 5.1, point 3: Since there are specific recommendations in many other cases, can something specific be said rather than "unnecessarily frequently"? Like, for example, "a few times initially and once a day thereafter".
> On the other hand, Section 5.2, next to last paragraph says "no more than twice in in a row" so maybe that is what is meant.

Registries expressed that this is not an interoperability requirement, and they would like notification details to be part of their business decisions. The exemplary guidance "no more than twice in in a row" is therefore given in the analysis (Section 5.2) but not the recommendation itself (Section 5.1).

I can imagine that gTLD registries might eventually create some policy about this in the ICANN space, and perhaps it's better for this RFC to not stand in the way at that point.

> Section 5.2, after the numbered points: Consistent with the tone of other parts of this document, I suggest "would be justified to attempt communicating" -> "SHOULD communicate"

This a derivation of the recommendation and not the recommendation itself. The SHOULD in recommendations 5.1.1-5.1.3 is the conclusion of that derivation.

> Section 7.1, point 1: "SHOULD" -> "MUST" ?

Fair point. As this technically would change WG consensus, I'll leave this to the IESG. (Context: I believe there was no explicit discussion and I can imagine nobody feels strongly.)

> Section 7.2.3, 1st paragraph: I understand the basis for saying DS flapping will only occur for a limited period of time. Is that the only basis for saying it will only be a minor nuisance?

The main point is that even when there is DS flapping for some period of time, both variants of the DS RRset will be valid, so it doesn't matter. Quoting:

    lead to flapping of DS updates.  However, it is not expected to be
    harmful as either DS RRset will allow for the validation function to
    continue to work, as ensured by Recommendation 1b of Section 4.  The
    effect subsides as the Child's state eventually becomes consistent
    (roughly, within the child's replication delay); any flapping until
    then will be a minor nuisance only.

As you didn't make a suggestion and I believe the text says the thing you raised, I did not apply a change for now.

> # Nits
> 
> Section 3, 2nd paragraph, first sentence. Not grammatical. Simplest change would be to delete "as" but it is also too wordy. Suggest shortening to "Recommendations in this document optimize interoperability and safety."

Done

> Section 4.1 point 1a and Appendix A.1, point 1a: "ambigious" -> "ambiguous"

Already fixed in -06

> Section 4.2.1, first line of last paragraph: perhaps the "may" should be "MAY".

This previously was the case (before -05), but the normative language here was removed upon AD Review.

> Section 6.2.2, last line: Some superfluous waffle wording here. "It therefore appears that DS initialization and rollovers should ..." -> "DS initialization and rollovers SHOULD ..."

Done

> Section 7.1, point 5: "has declared to be performing automated" -> "has declared it performs automated"

Done (with "that" added), also in summary A.4.

> Section 7.2.1, 1st paragraph, 2nd sentence: "the key used by for authentication" -> "the key used for authentication"

Done

> Section 7.2.2, 2nd paragraph: suggest "It is therefore advised to not follow this practice." -> "This practice is NOT RECOMMENDED."

Done

> Section 7.2.2, 4th paragraph: ends with a parenthetical where I believe the parens are not needed. Check for other cases of this in the document.

Prefer to keep it, as otherwise it reads like a restriction whereas the parenthetical is for context only.

> Section 11: Spell out SSAC on first use.

Done.

The combined diff of the above changes is here: https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/0b89e97dde78126190453d833f8378c52f34f430

Best,
Peter