On Sun, 1 Feb 2026, Steve Crocker wrote:
The motivation for documenting the life cycle is to make both implementers and operators aware there are seven phases and there's a rationale for defining this many phases. Documents that give a snapshot of which algorithms are currently recommended, not recommended, etc. don't provide that perspective.
RFC8624 already said: Although this document's primary purpose is to update algorithm recommendations to keep DNSSEC authentication secure over time, it also aims to do so in such a way that DNSSEC implementations remain interoperable. DNSSEC interoperability is addressed by an incremental introduction or deprecation of algorithms. [...] It is expected that deprecation of an algorithm will be performed gradually in a series of updates to this document. This provides time for various implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of to MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a RECOMMENDED instead of a MUST. Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure, it is recommended that algorithms downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs. This will allow for deprecated algorithms to become less and less common over time. Once an algorithm has reached a sufficiently low level of deployment, it can be marked as MUST NOT so that recursive resolvers can remove support for validating it. And RFC9904 says: 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. [...] The perspective of implementers may differ from that of an operator who wishes to deploy and configure DNSSEC with only the safest algorithm. As such, this document also adds new recommendations about which algorithms should be deployed regardless of implementation status. In general, it is expected that deployment of aging algorithms should generally be reduced before implementations stop supporting them. [...] By the time a DNSSEC cryptographic algorithm is made mandatory to implement, it should already be available in most implementations. [...] It is expected that the deprecation of an algorithm will be performed gradually. This provides time for implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of directly from MUST to MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory to implement is expected to be first introduced as RECOMMENDED instead of a MUST.Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure, it is recommended that algorithms that have been downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs. This ensures that the use of deprecated algorithms decreases over time. Once an algorithm has reached a sufficiently low level of deployment, it can be marked as MUST NOT, so that recursive resolvers can remove support for validating it. Validating recursive resolvers are encouraged to retain support for all algorithms not marked as MUST NOT. I do not understand why implementers or operators need more background information. The RFCs above have been saying "Here is some background on why we made these choices are carefully considerating, do things differently at your own peril". These RFCs also did not use the explicit lifecycles phases you are proposing, although obviously there is a large overlap with that and the above quoted background information on why the IANA registry looks as it does.
Regarding the decisions as to when a particular algorithm should be moved from one phase to the next, I agree this is not a simple process. The crypto experts will provide guidance on when a new algorithm has passed their analysis and testing and when an existing algorithm should be phased out. Those judgments cover two of the six transitions, A and D. The other transitions depend on deployment and use. I didn't propose the specific means for measuring those, but I did include a requirement for a designated set of experts to make those judgments.
I believe the process of using DNSOP as the group of experts worked fine for RFC8624 and RFC9904. That is _exactly_ what DNSOP is chartered to do. I would be concerned if we reduce that group to a few (non-democratically) selected designated experts.
I would expect they will develop procedures, tools and criteria to do this work. And to your point in your follow-up note that people pay more attention to RFCs than current values in IANA registries, the decisions made by the designated experts at each transition will indeed be documented in RFCs. And likely publicized in other venues.
Assuming those would be BCPs or Standard Track RFCs, that requires DNSOP activity then?
Implementers, i.e. the folks in control of software crypto packages, will make their own decisions, of course, but the intent here is to give them clear guidance, with accompanying data, to make their decisions much easier. Similarly, operators, i.e. the folks in control of which algorithms in the crypto packages are enabled or disabled in their services, will also find the guidance helpful.
I think DNSOP has done that with RFC8624 and RFC9904 and I see them doing the same for 9904bis once the time is right. Paul _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
