]> Edgemoor Research Institute

steve@shinkuro.com

Vigil Security, LLC

housley@vigilsec.com

Google LLC

ietf@hardakers.net

Internet-Draft Cryptographic algorithms go through multiple phases during their lifetime: experimental, adopted, generally available, in mainstream use, phasing out, deprecated, and obsoleted. This document defines phases for algorithm deployment lifecycles within DNSSEC, and criteria that the IETF and/or other Standards Development Organizations are encouraged to use when moving an algorithm from one phase to the next. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Background Each DNSSEC cryptographic algorithm is used in two distinct but interconnected ways. The first occurs when a domain owner signs their DNS records using a DNSSEC algorithm. The second occurs when a DNSSEC validator verifies that the DNSSEC signatures are correct. If someone uses a DNSSEC algorithm to sign DNS records, the party that receives that signed set of DNS records needs to be able to validate the signatures for them to be useful. Importantly, this means receiving parties need to implement a validation algorithm before the sending parties can expect to use it effectively. Equally, the receiving parties have to keep the validation algorithm in service until all signing parties stop using it. These relationships seem obvious in hindsight, but there has not been an organized way to communicate the current phase of a DNSSEC algorithm within the Internet community and when transitions between them should and do occur. This document builds upon the enhancements defined in to the IANA "DNS Security Algorithm Numbers" registry and the IANA "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry ; the columns in these registries enable us to describe the lifecycle phase that an algorithm is in. This document suggests additional structure to those tables by stating the values that need to be encoded within them. In turn, this enables the IETF or other Standards Development Organizations (SDOs) to document their current phasing points as algorithms traverse into and out states during their lifetimes. Note that this document uses conventions from the IANA DNSSEC algorithm tables with the values defined in , but similar documentation methodologies may exist within other SDOs. This document also discusses how the IETF and other SDOs can ensure the DNSSEC ecosystem always remains in a resilient cryptographic state, where publishers and verifies widely, if not completely, agree to a minimal set of algorithms that must be available for use even as the collection of algorithms simultaneously traverse through independent lifecycles.

The Seven Phases in the Lifecycle of a DNSSEC Algorithm This document defines seven phases in the lifecycle of an individual 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 ensure other algorithms are available for signers and versifiers can transition to. Signing should be phased out.

6. Deprecated:

   All use for signing should have stopped, but signature validation is still supported to support the last signers that are delayed in transitioning.

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 seven transition points, labeled A through G, between these seven lifecycle phases. The following subsections describe a process and criteria for each of these transitions. These transitions points are idealistic in nature and describe when algorithms are safely able to transition with reasonable stable times between each of the steps. External factors, such as sudden advances in cryptographic attacks, may lead to some algorithms transitioning more rapidly than desired, or even jumping states entirely in extreme cases (for example transitioning from Adopted to Depreciated if a newer algorithm is suddenly determined to be insecure). Similarly, very experimental algorithms may never even reach an Adopted state if they fail to show promise for use within DNSSEC. Note: in the text below there are descriptions indicating that the SDO (for example, the IETF) should perform some action (such as "the SDO publishes notice"). This document does not define how these actions should be implemented. Some actions may require simple mailing list discussions, some may require formal standards actions, etc. This document concentrates on the goals for properly communicating phasing and not the formality semantics required to do so. For each of the steps below, in addition to the actions listed for each step, the SDO will need to publish updates to the "DNS Security Algorithm Numbers" registry and the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry using values from Table 1.

A. Transition into Experimental

• Prerequisites:
  • An algorithm has been created along with a document describing how it can be used within DNSSEC.

B. Transition into Adopted

• Prerequisites:
  • The algorithm has been given a Mnemonic and code-point assignment in the "DNS Security Algorithm Numbers" registry .
  • The cryptographic community has determined that the algorithm as suitable to use for DNSSEC.
  • Documentation and implementations are widely available and stable.
• The SDO has also determined that the algorithm is suitable for use with DNSSEC.
• Action: The SDO publishes notice that the algorithm is suitable for use and may be deployed for signature validation.

C. Transition into Available

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

D. Transition into Mainstream

• The SDO reaches consensus that the algorithm has reached Mainstream status as deployment is essentially universal.
• Actions:
  • Validation and signing deployment has been measured.
  • The SDO publishes notice that the algorithm has reached Mainstream status.
  • Signers using older algorithms, particularly algorithms in the Phaseout or later phases should transition to a Mainstream or Ready To Use algorithm.

E. Transition into Phaseout

• Prerequisites:
  • The cryptographic community has determined the algorithm is reaching its end of life.
• The SDO determines announces the DNSSEC algorithm is being phased out.
• Action: The SDO publishes notice to signing operators that they should transition away from the algorithm and begin signing with an algorithm listed as Mainstream or Ready To Use.

F. Transition into Deprecated

• Prerequisites:
  • Signing activity has been measured.
  • Signing activity is deemed to have largely subsided.
• The SDO determines the DNSSEC algorithm should be deprecated for usage.
• Action: The SDO publishes notice that use of the algorithm is now inappropriate for DNSSEC signing.

G. Transition into Obsolescence

• Prerequisite:
  • Deployment has been measured.
  • Deployment is deemed to have reached the lowest achievable level of signing.
• The SDO determines the algorithm is obsolete.
• Action: The SDO publishes notice that algorithm is obsolete and can be removed from implementations.

Lifecycle Phase and the IANA Registry This document provides guidance about the values to be encoded within the implementation and usage columns from the IANA registry of DNSSEC algorithms defined in . Specifically, Table 1 suggests the values to be placed into each of the IANA registry columns "Use for DNSSSEC Signing", "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", and "Implement for DNSSSEC Validation" columns for each phase in algorithm lifecycles defined in . The IETF and other SDOs are encouraged to consider use of Table 1 when assigning IAN or other registry values. Note that at times, particular values associated with past assignments, may not match the guidance encoded in this document. This might be due to values created prior to this guidance being offered, or when the SDO needs to document very unusual corner cases that deviate from the guidance this document offers.

Applicability Note that within the IETF, per , this phasing approach is only suggested for algorithms that are being proposed for standards track documents since all other algorithms cannot obtain states other than MAY, NOT RECOMMENDED, or MUST NOT. Other organizations are encouraged to make use of this Lifecycle Phasing approach if they are able to as well.

A case study: the RSASHA1 signing algorithm Before and this document were written, the RSASHA1 algorithm entered a problematic state where there was still significant deployment of RSASHA1 when one operating system stopped distributing DNSSEC validating resolvers that supported the RSASHA1 algorithm. This uncoordinated difference between deployments of DNSSEC publishers and DNSSEC validators left some zones in an unprotected state. Had the industry followed the Lifecycle Phasing approach in this document, this situation could have been mitigated.

Considerations for maintaining a robust DNSSEC algorithm state The above sections consider the values associated with a particular algorithm in the IANA registry for "DNS Security Algorithm Numbers" and the IANA registry for "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" using values from Table 1. It is equally as important to ensure that as algorithms come into and out of favor that the current set of available algorithms always includes at least one algorithm that is in the Mainstream state. As the SDO considers transitioning a particular algorithm beyond the Mainstream state, it ought to simultaneously ensure that at least one other algorithm is already present in the Mainstream state or that one other algorithm is in the Ready to Use state and available to simultaneously become a Mainstream algorithm. Specifically, at no time should there be zero algorithms in the Mainstream state.

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 algorithms will occur in a smooth manner that ensures deployed implementations will be able to validate published signatures. Likewise, following the criteria will ensure that out-of-date DNSSEC algorithms are retired in a graceful manner. The criteria associated with how to effect documenting the transition between phases of the lifecycle will depend on the process that makes changes to the IANA registry as defined in . If the industry fails to achieve global consensus on the state of any one algorithm such that domain owners deploying signing zones disagree with the deployed validating resolvers, then it likely that DNS resolutions will fail which in turn will render some portion of the DNS as unusable. As such, vendors of both authoritative and recursive resolvers, and the operating systems that deploy them, are encouraged to collaborate about the current phases and transitions of DNSSEC algorithms and to strictly follow the guidance in order to avoid DNS interoperability issues.

Informative References The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of nonexistence. 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 replaces and obsoletes RFC 8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries. This is done to allow the list of requirements to be more easily updated and referenced. Extensions to these registries can be made in future RFCs. This document also updates RFC 9157 and incorporates the revised IANA DNSSEC considerations from that RFC. This document does not change the recommendation status (MUST, MAY, RECOMMENDED, etc.) of the algorithms listed in RFC 8624; that is the work of future documents. IANA n.d. IANA n.d.

Acknowledgments Thanks to Warren Kumari for constructive comments.