]> Edgemoor Research Institute

steve@shinkuro.com

Vigil Security, LLC

housley@vigilsec.com

DNSOP Working Group Internet-Draft Cryptographic algorithms for DNSSEC go through multiple phases during their lifetime. They are created, tested, adopted, used, and deprecated over a period of time. This RFC defines phases for the DNSSEC algorithm lifecycle, and it defines the criteria for moving from one phase to the next.

Background Each DNSSEC cryptographic algorithm is used in two distinct but interconnected ways. The first is to sign. The second is to validate a signature. If someone uses an algorithm to sign, the party that receives that signed message should be able to validate the signature. This means the receiving parties need to implement the validation algorithm before the sending parties can expect to use it effectively, and equally, the receiving parties have to keep the validation algorithm in service even after the signing parties stop using it. These relationships seem obvious, but there has not been an organized way to communicate within the Internet community regarding these algorithm transitions. This document builds upon the enhancements defined in to the IANA registry of DNSSEC algorithms; the values in the "Use for DNSSSEC Signing", "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", and "Implement for DNSSSEC Validation" tell which phase the algorithm is in with respect to this lifecycle.

Seven phases in the lifecycle of a DNSSEC algorithm We define seven phases in the lifecycle of a DNSSEC algorithm.

1. Experimental: The algorithm is under development by the cryptographic community and is not yet ready for general use.
2. Adopted: The algorithm is ready to be used by the Internet community. It is listed in the IANA registry. Implementers are expected to support the algorithm for signature validation.
3. Available: The algorithm is ready for use by all parties. Implementers are expected to support the algorithm for signing and signature validation.
4. Mainstream: The algorithm has reached “recommended” status. Implementers are expected to support the algorithm for signing and signature validation.
5. Phaseout: The algorithm is nearing the end of its lifecycle, but it is still in use. Implementers are advised to transition to other recommend algorithms. Signing should be phased out.
6. Deprecated: All use for signing should have stopped, but signature validation is still supported.
7. Obsolete: No support for signing or signature validation is expected.

Process and Criteria for transitions The previous section does not specify the process and criteria for advancing a DNSSEC algorithm through these lifecycle phases. There are six transition points, labelled A through F, between these seven lifecycle phases. We propose the following process and criteria for these transitions. A. Algorithm Inclusion

• Prerequisites:
  • Algorithm has been given a Mnemonic and number in the "DNS Security Algorithm Numbers" registry.
  • Cryptographic community has determined that the algorithm as suitable to use for DNSSEC.
  • Documentation and implementations are widely available and stable.
• IETF determines the algorithm is suitable for use with DNSSEC.
• Action: IETF publishes notice that the algorithm is suitable for use and should be deployed for signature validation.

B. Ready for Use

• Prerequisites:
  • Deployment has been measured.
  • Deployment is deemed to have reached an acceptable level.
• IETF reaches consensus that algorithm has been widely deployed for DNSSEC.
• Action: IETF publishes notice that algorithm is available for DNSSEC signing.

C. Mainstream

• IETF reaches consensus that algorithm has reached mainstream status.
• Actions:
  • IETF publishes notice that algorithm has reached mainstream status.
  • Signers using older algorithms, particularly algorithms in the Phaseout or later phases should transition to a mainstream algorithm.

D. Phaseout

• Prerequisites:
  • Cryptographic community has determined the algorithm is reaching its end of life.
• IETF determines it is time to announce the phaseout.
• Action: IETF publishes notice to signing operators to transition away from the algorithm and begin signing with a mainstream algorithm.

E. Deprecation

• Prerequisites:
  • Measure signing activity.
  • Signing activity is deemed to have largely subsided.
• IETF determines it is time to deprecate the algorithm for use with DNSSEC.
• Action: IETF publishes notice that use of the algorithm is now inappropriate for DNSSEC signing.

F. Obsolescence

• Prerequisite: Measurement of signing is at the lowest achievable level.
• IETF determines the algorithm is obsolete.
• Action: IETF publishes notice that algorithm is obsolete and ought be removed from implementations.

Lifecycle Phase and the IANA Registry The enhancements to the IANA registry of DNSSEC algorithms defined in . Table 1 suggests the values for the IANA registry values in the "Use for DNSSSEC Signing", "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", and "Implement for DNSSSEC Validation" columns for each phase in the algorithms lifecycle defined in . The IETF is encouraged to follow Table 1 in assigning the values in the IANA registry of DNSSEC algorithms as each algorithm progresses through the lifecycle.

IANA Considerations IANA has no actions related to this document.

Security Considerations This document proposes a lifecycle for DNSSEC algorithms. By following the criteria presented in , Internet-wide deployment of new DNSSEC algorithm will occur in a smooth manner that ensures all implementations will be able to validate signatures. Likewise, following the criteria will ensure that out-of-date DNSSEC algorithm are retired in a graceful manner. The criteria associated with the transition between phases of the lifecycle will depend on the process that makes changes to the IANA registry as defined in .

References Normative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References USC/ISI Google <EDITOR NOTE: This document does not change the status (MUST, MAY, RECOMMENDED, etc) of any of the algorithms listed in [RFC8624]; that is the work of future documents. Instead, this document moves the canonical list of algorithms from [RFC8624] to an IANA registry. This is done for two reasons: 1) to allow the list to be updated more easily, and, much more importantly, 2) to allow the list to be more easily referenced.> 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. Future extensions to this registry can be made under new, incremental update RFCs.