Internet DRAFT - draft-crocker-dnsop-dnssec-algorithm-lifecycle
draft-crocker-dnsop-dnssec-algorithm-lifecycle
DNSOP Working Group S. Crocker
Internet-Draft Edgemoor Research Institute
Intended status: Informational R. Housley
Expires: 3 September 2024 Vigil Security
2 March 2024
Documenting and Managing DNSSEC Algorithm Lifecycles
draft-crocker-dnsop-dnssec-algorithm-lifecycle-00
Abstract
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 these phases, and
defines the criteria for moving from one phase to the next.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Crocker & Housley Expires 3 September 2024 [Page 1]
Internet-Draft DNSSEC Algorithm Lifecycles March 2024
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Seven phases in the lifecycle of a DNSSEC algorithm . . . . . 2
3. Process and Criteria for transitions . . . . . . . . . . . . 3
4. Expert Panel . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. 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 use expect to
use it effectively, and equally, the receiving parties have to keep
the validation algorithm in service well after the signing parties
stop using it.
These relationships seem obvious, but there has not been an organized
way to communicate to the Internet community when these algorithm
transitions take place. This document proposes that IANA augment its
registry of DNSSEC algorithms with the status of each algorithm with
respect to this lifecycle.
2. 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.
Crocker & Housley Expires 3 September 2024 [Page 2]
Internet-Draft DNSSEC Algorithm Lifecycles March 2024
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.
3. 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.
Crocker & Housley Expires 3 September 2024 [Page 3]
Internet-Draft DNSSEC Algorithm Lifecycles March 2024
* 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.
Crocker & Housley Expires 3 September 2024 [Page 4]
Internet-Draft DNSSEC Algorithm Lifecycles March 2024
* IETF determines the algorithm is obsolete.
* Action: IETF publishes notice that algorithm is obsolete and ought
be removed from implementations.
4. Expert Panel
Determination of when an algorithm has reached a particular
transition point will require a panel of experts. We propose that
the IESG select the individuals for this panel as the IANA Designated
Experts [RFC8126] for the "DNS Security Algorithm Numbers" registry.
The individuals that make up the Expert Panel are expected to have
contacts within the cryptographic community to determine whether a
particular algorithm is suitable for use with DNSSEC.
5. IANA Considerations
IANA is asked to add a "Lifecycle Phase" column to the "DNS Security
Algorithm Numbers" registry. Once the Expert Panel discussed in the
previous section is seated, the Expert Panel will tell IANA the
appropriate lifecycle phase for each algorithm that is in the
registry.
For future additions to the registry, they will initially be listed
in Phase 1 (Experimental). Changes to the lifecycle phase will be
determined by the Expert Panel.
6. Security Considerations
This document proposes a lifecycle for DNSSEC algorithms. By
following the criteria presented in Section 3, 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 judgement of the Expert Panel that will be chosen by the IESG.
7. Normative References
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
Crocker & Housley Expires 3 September 2024 [Page 5]
Internet-Draft DNSSEC Algorithm Lifecycles March 2024
Appendix A. Change History
(RFC Editor: Please remove this section before publication.)
* draft-crocker-dnsop-dnssec-algorithm-lifecycle-00
Initial public draft.
Authors' Addresses
Steve Crocker
Edgemoor Research Institute
Email: steve@shinkuro.com
Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
Crocker & Housley Expires 3 September 2024 [Page 6]
