Hi,
Thanks for the update. The new text contains "DNSSSEC" in multiple instances (one extra
"S").
Section 2.1 ("Column Descriptions"):
This Section is new. It talks about "intended usage of the four columns",
presumably as listed in Table 1.
- However, Table 1 defines six new columns, not four. (Section 2.1 is missing the ones
about "signing".)
- For the "validation" columns, I suggest the following changes (there are
non-resolver validators):
OLD
Use for DNSSEC Validation: Indicates the algorithm's recommended
usage for validation in validating resolvers.
/
Implement for DNSSEC Validation: Indicates the recommendation for
implementing the algorithm within validating resolvers.
NEW
Use for DNSSEC Validation: Indicates the recommendation for using
the algorithm in DNSSEC validators.
/
Implement for DNSSEC Validation: Indicates the recommendation for
implementing the algorithm within DNSSEC validators.
... or similar.
Section 2.2 ("Adding and Changing Values"):
The new paragraph ("Only values ...") says something about the "Use for DNSSEC Signing" column and the two
"Use for DNSSEC Validation" columns, ditto for "implement". The allowed values for the two
"delegation" columns are missing. Is this intentional?
Section 6 ("Operational Considerations") has the following:
OLD
Upgrading algorithm at the same time as rolling to the new Key
Signing Key (KSK) key will lead to DNSSEC validation failures, and
users MUST upgrade the DS algorithm first before rolling to a new
KSK.
This sound like one can deploy a DS record for an algorithm that has not
DNSKEYs or RRSIGs in the child. This would currently be a violation of RFC 6840
Section 5.11.
I may well have misunderstood, but if not, I would suggest dropping this
paragraph, especially as this rule may be changed (authors of
draft-huque-dnsop-multi-alg-rules haven't given up).
Best,
Peter
On 5/21/25 00:49, [email protected] wrote:
Internet-Draft draft-ietf-dnsop-rfc8624-bis-10.txt is now available. It is a
work item of the Domain Name System Operations (DNSOP) WG of the IETF.
Title: DNSSEC Cryptographic Algorithm Recommendation Update Process
Authors: Wes Hardaker
Warren Kumari
Name: draft-ietf-dnsop-rfc8624-bis-10.txt
Pages: 15
Dates: 2025-05-20
Abstract:
The DNSSEC protocol makes use of various cryptographic algorithms to
provide authentication of DNS data and proof of non-existence. To
ensure interoperability between DNS resolvers and DNS authoritative
servers, it is necessary to specify both a set of algorithm
implementation requirements and usage guidelines to ensure that there
is at least one algorithm that all implementations support. This
document updates RFC8624 by moving the canonical source of algorithm
implementation requirements and usage guidance for DNSSEC from
RFC8624 to an IANA registry. This is done both to allow the list of
requirements to be more easily updated, and to allow the list to be
more easily referenced. Future extensions to this registry can be
made under new, incremental update RFCs. This document also
incorporates the revised IANA DNSSEC considerations from RFC9157.
The document does not change the status (MUST, MAY, RECOMMENDED,
etc.) of the algorithms listed in RFC8624; that is the work of future
documents.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8624-bis-10
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8624-bis-10
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Möckernstraße 74
10965 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
