| Internet-Draft | Current practices for new cryptography | November 2024 |
| Wouters | Expires 7 May 2025 | [Page] |
This document describes the current practices for handling new cryptography within the IETF. Some of these practices are informal and depend on individuals in certain relevant roles, such as Working Group Chairs, the Security Area Directors and the Independent Stream Editor. This document is intended to increase consistency and transparency in how the IETF handles new cryptography, such as new algorithms, ciphers and new primitives or combiners, by providing a reference for the cryptographic practices within the IETF. This document does not describe any new policies and does not prohibit exceptions in the described current practices.¶
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 7 May 2025.¶
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.¶
The goal of the IETF is to continuously use and evolve the cryptography used in their protocols. While "the best cryptography" is a theoretical goal, in practice this means the IETF tries to limit itself by adopting only solidly researched and properly tested modern cryptography that have the right properties for the protocol it is intended for. Another goal is to avoid a proliferation of mostly equivalent cryptographic choices to keep operational complexities at a minimum. There is a cost in complexity for having many specifications, implementations and integrations of cryptography. There is also an operational cost of deploying cryptographic updates at internet scale and time.¶
The history of cryptography and the IETF goes back to the 1990s. As such, any current policy described now will be inconsistent with how some decisions were made in the past. Cryptographic algorithms have been published by Working Groups, Research Groups, via Area Director sponsoring ("AD Sponsored") and via the Independen Stream (ISE).¶
Published RFCs have included specifications of cryptographic algorithms. Examples are MD5 [RFC1321], SHA1 [RFC3174], SHA2 [RFC6234], GOST [RFC4357], Brainpool [RFC5639], Curve25519/Curve448 [RFC7748] and CAMELLIA [RFC6234]. Current practise is to avoid specifying cryptographic algorithms and instead try yo refer to such algorithms via an external normative reference.¶
Published RFCs have also included profiles of cryptographic algorithms that define specific use cases where additional operational constrains apply. Examples of these are the Suite B profiles (e.g. [RFC5430]) published via Area Director Sponsorship ("AD sponsored") and the CNSA profiles (e.g. [RFC8603]) and GOST (e.g. [RFC7836]) profiles published via the Independent Stream Editor (ISE).¶
RFCs have been published to document requested OIDs or other algorithm identifers for cryptographic algorithms. An example of this for X.509 identifiers is [RFC8410].¶
The distinction between a profile and a specification has not always been very strict, especially when the original specification was not available in English online. An example of a combined specification with profile is GOST [RFC7836].¶
The IETF depends on public cryptographic communities outside the IETF. These communities consists of academia, vendor associated cryptographers, and various cryptographic groups, conferences, meetings and competitions.¶
There are some researchers and engineers participating both in the cryptographic communities as well as being part of the IETF.¶
The IRTF acts as an experts group of researchers that advise the IETF community, and it has a specific research group, the Crypto Forum (CFRG) to assist the IETF in their evaluation and choices of cryptography in internet protocols. CFRG cannot publish standards track documents because it is a Research Group and not an IETF Working Group. The CFRG writes informational or experimental RFCs that describe the properties of certain cryptographic primitives and how to use them. IETF working groups may then normatively references those RFCs from standards track RFCs.¶
CFRG does not work on defining its own cryptographic primitives, although it sometimes helps with writing specifications on how to use certain cryptographic primitives within IETF documents, for example Hybrid Public Key Encryption (HPKE) [RFC9180] and ChaCha20 and Poly1305 for IETF Protocols [RFC7539].¶
The Crypto Panel (https://wiki.ietf.org/group/cfrg/CryptoPanel) is a volunteer review panel that's organised as part of CFRG. Review requests for the Crypto Panel are communicated to the CFRG chairs, who will request the crypto panel review as appropriate. While it looks like an IETF Directorate, it does not work exactly like these. For example, it has no capacity to take requests from anyone in the community. Its reviews are advisory.¶
Some Working Groups have been the early adopters of cryptographic primitives and have been able to do so based on strong participation of cryptographers in those working groups. Example of these are TLS, LAMPS, PKIX, CURDLE, MLS and IPsecME.¶
While a proliferation of cryptographic primitives and algorithms are unwanted, the IETF encourages experimenting with new cryptographic components. Code Points are meant to be easy to obtain, as the IETF encourages experimentation and getting operational experiences.¶
This is facilitated by writing Experimental or Informational drafts and getting Code Points in the related IANA Registries to run those experiments at internet scale. This does not require an RFC. And since RFCs are often mistakenly seen as acceptance by the IETF as a standard to people outside the IETF, using drafts with Code Points is the preferred method for testing out new cryptography.¶
The IETF's goal is not to issue cryptographic RFCs based on the intrinsic value to the authors or their representatives for getting an RFC allocation.¶
For example, having an RFC number might be more persuasive to a vendor to implement a certain cryptographic algorithm. Unfortunately, this exact reason is also why it is misleading for the IETF to assign RFCs to such cryptographic algorithms as it would appear to the outside community that these cryptographic algorithms have strong IETF wide consensus for implementation.¶
In the past, IANA Registries were very strict with allowing new code point allocations for cryptographic components. A number of IANA Registries, for example for TLS, IPsec/IKEv2 and SSH were updated to make it easier to allow for such experimentation. Where possible, IANA Registries for cryptographic algorithms have an open registration policy ("Expert Review" or "Specification Required") that can be used by draft documents.¶
There are some IANA Registries where the limited allocation space does not allow for handing out many experimental code points, for example DNSSEC (DNSKEY). This necessitates a more conservative approach to code point allocation. It might force experimentation to (re)use Private Use Code Points.¶
Other IANA Registries use a "vendorized" string based allocation scheme that allows for unlimited code points, for example SSH [RFC4253]. This allows for wide experimentation in a "vendor space" that acts as a Private Use registration, which can later be converted to a non-vendorized allocation in case of a cryptographic algorithm seeing IETF-wide consensus. For such registries, inclusion in the non-vendorized space is only done for RECOMMENDED algorithms.¶
The specification of a new cryptographic algorithm that is a drop-in replacement for another algorithm does not need a specification within the IETF. Such specification is references via a normative reference to an external document.¶
It could be however, that such an algorithm would need some advise on how to use it safely within IETF protocols. Such advise could be published in a Profile RFC by CFRG as it would apply to all IETF protocols. An example of this is "ChaCha20 and Poly1305 for IETF Protocols" [RFC7539]. Note that as per [RFC2014] RFCs published by CFRG have no automatic standing in IETF unless the IETF has published a Standards Track or BCP RFC giving them standing.¶
If the specification is not available in English, it could be published in an RFC including a proper disclaimer at the top of the document through the Independent Stream to better indicate that the algorithm has not seen the review and acceptance of the algorithm through the IETF process and that change control for the algorithm was not transfered to the IETF. The algorithm would likely also need advise on how to use the algorithm within IETF protocols. This would be more appropriate as a Profile RFC, which could then publish the specification itself in an Appendix.¶
New cryptographic primitives would need an RFC. The IETF does not invent its own cryptography, but rather references cryptographic mechanisms defined elsewhere. In the uncommon case that new cryptography is needed, the IRTF CFRG provides a forum for development and review.¶
Most IANA Registries for cryptographic algorithms have a field, such as Status or Recommended, that indicates whether the algorithm is recommended to implement or use. IANA Registries that do not have such a field can be brought up in the working group to be modified to include such a field.¶
Having too many RECOMMENDED algorithms is considered harmful as it complicates both implementations, deployments and migrations to newer algorithms.¶
Especially for protocols that do not have an online negotiation phase, such as encryption algorithms for OPENPGP, it is important that the registries are not filled with no longer RECOMMENDED algorithms that need to be supported indefinitely (e.g. to read very old encryped emails)¶
Deciding on a RECOMMENDED status ideally comes after an IETF wide community acceptance of the algorithm, and not be based only on the views within a single Working Group. An exception to this would be protocol specific considerations, although that is more appropriate for cryptographic primitives than for more or less drop-in replacements of cryptographic algorithms.¶
Decisions on setting or removing a RECOMMENDED flag are intended to require a Standards Track RFC. That is, Independent Stream and IRTF RFCs cannot set or clear RECOMMEND fields.¶
This document contains no actions for IANA.¶
This document clarifies IETF process on cryptographic algorithms and has no specific Security Considerations.¶
How to fit in "clever" crypto inventions, eg PPM?¶
How to fit in combinatorics, hybrid constructions, etc?¶