Paul Wouters has entered the following ballot position for draft-ietf-dnsop-cds-consistency-09: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/ ---------------------------------------------------------------------- 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. 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. 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? 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: The following acceptance rules are placed on the CDS and CDNSKEY resource records as follows: o Location: MUST be at the Child zone apex. o Signer: MUST be signed with a key that is represented in both the current DNSKEY and DS RRsets, unless the Parent uses the CDS or CDNSKEY RRset for initial enrollment; in that case, the Parent validates the CDS/CDNSKEY through some other means (see Section 6.1 and the Security Considerations). RFC9516 updates this but also requires another signal in that case: https://datatracker.ietf.org/doc/html/rfc9615#signaling _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
