Hi Paul,
Thank you for your ballot and for your thorough review! Answers inline.
On 11/18/25 04:47, Paul Wouters via Datatracker wrote:
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-cds-consistency-09: Yes
[...]> ----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I did not raise my comments to the level of DISCUSS, but it would be good to
have a discussion on these items. I do believe it is always better to insist on
consistencies, hence not raising these to discuss level.
Readers are expected to be familiar with DNSSEC, including [RFC4033],
[RFC4034], [RFC4035], [RFC7344], and [RFC7477],
Note the canonical reference for DNSSEC these days is RFC9364. As that draft
states:
One purpose is to introduce all of the RFCs in one place so that the reader
can understand the many aspects of DNSSEC. This document does not update any
of those RFCs. A second purpose is to state that using DNSSEC for origin
authentication of DNS data is the best current practice. A third purpose is
to provide a single reference for other documents that want to refer to
DNSSEC.
So that seems to exactly match the use here.
Right. I've changed the text as follows (to be submitted after the telechat, so
happy to apply more changes):
OLD
Readers are expected to be familiar with DNSSEC, including [RFC4033],
[RFC4034], [RFC4035], [RFC7344], and [RFC7477], and may refer to
[RFC6781] and [RFC8901] for an overview of DNSSEC operational
practices.
NEW
Readers are expected to be familiar with DNSSEC [RFC9364], in
particular [RFC4033], [RFC4034], [RFC4035], [RFC7344], and [RFC7477].
For an overview of related operational practices, refer to [RFC6781]
and [RFC8901].
Rationale:
- Besides referencing DNSSEC as a whole, I think it's worthwhile pointing the
reader to the specific bits that are directly related to this document.
- The "operational practices" phrase was introduced after a review by Med.
During initial DS provisioning (DNSSEC bootstrapping), conventional DNSSEC
validation for CDS/CDNSKEY responses is not (yet) available; in this case,
authenticated bootstrapping ([RFC9615]) should be used.
Or a regular EPP method can be used instead of trying to bootstrap through DNS.
This is in the CDS/CDNSKEY section, explaining how to use that technique
properly (which entails updates and bootstrapping).
I'll be happy to add that a provisioning protocol like EPP can also be used
(not only for DS bootstrapping, but also for DS updates as well as NS updates),
but that would have to go elsewhere in that document. OTOH, I don't think it's
needed as the doc is specifically about clarifying aspects of CDS/CDNSKEY and
CSYNC.
who may then inadvertently break the chain of trust by prematurely removing
a DNSKEY still referenced by a (stale) CDS/CDNSKEY RRset.
I am confused here. How can one "prematurely" remove a DNSKEY that is
referenced by a (stale) CDS/CDNSKEY ?? I think you mean "accidentally" remove a
newly introduced DNSKEY that is not referenced by a (stale) CDS/CDNSKEY?
No. Let's say you want to roll to a different algorithm, say from alg 8 to 13,
and the parent processes CDNSKEY after 1 day maximum.
Steps (between each, wait for TTL etc; signature addition/removal not spelled
out in detail):
step 0:
- DNSKEY is KSK_8
- CDNSKEY is KSK_8
[DS record points to KSK_8]
step 1:
- DNSKEY is KSK_8 and KSK_13
- CDNSKEY is KSK_8
step 2:
- DNSKEY is KSK_8 and KSK_13
- CDNSKEY is KSK_8 and KSK_13
[after a day, the parent will have updated DS record to point to KSK_8 and
KSK_13]
step 3:
- DNSKEY is KSK_8 and KSK_13
- CDNSKEY is KSK_13
[wait for another day]
step 4:
- DNSKEY is KSK_13
- CDNSKEY is KSK_13
This is the normal process.
However, if one secondary is lagging, and the parent queries only that
secondary (not enforcing consistency), then the parent may only see the CDNSKEY
RRset from step 2, not from step 3, and not actually update the DS record. If
the child does not notice the stale secondary and orchestrates things only by
timing, it may remove KSK_8 from the DNSKEY RRset on the non-stale secondary
(step 4), which is then in algorithm mismatch with the DS RRset.
This is described by "inadvertently break the chain of trust by prematurely
removinga DNSKEY still referenced by a (stale) CDS/CDNSKEY RRset."
Similar issues can be constructed when only rolling a key (not algorithm),
where the stale secondary remains in step 0 or 1, i.e. the DS RRset does not
get updated but the child proceeds with the rollover nevertheless.
Now you can of course say that the child should not proceed if it doesn't see
the correct DS record. Note, however, that in the case of the algorithm
rollover, the child *does* observe the correct DS record. (And also, the
guidance is for how parents can prevent breakage, even when the child makes a
mistake.)
In particular, the rogue nameserver can publish CDS/CDNSKEY records. If
those are processed by the parent without ensuring consistency with other
authoritative nameservers, the delegation will, with some patience, get
secured with the attacker's DNSSEC keys.
Note as per RFC7344 this cannot happen. CDS/CDNSKEY records MUST validate
before being processed, or covered via an alternative method:
RFC 7344 is about updating DS records (where the old key signs the new
CDS/CDNSKEY RRset), whereas the cited example is about bootstrapping (where the
is no DS RRset yet).
RFC9516 updates this but also requires another signal in that case:
https://datatracker.ietf.org/doc/html/rfc9615#signaling
Correct. However, the attacker can use the same signaling when the control the
hijacked nameserver (such as after its domain registration expired). This will
only be detected if the parent looks for the signal under all nameserver
hostnames, not just one.
For this very reason, RFC 9615 requires parents to look under all nameserver
hostnames (Section 4.2 step 3), which is exactly the consistency check this
draft spells out in more general terms.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
