Current practices for new cryptography at the IETF
draft-pwouters-crypto-current-practices-00

Network                                                  P. Wouters, Ed.
Internet-Draft                                                     Aiven
Intended status: Informational                           3 November 2024
Expires: 7 May 2025

           Current practices for new cryptography at the IETF
               draft-pwouters-crypto-current-practices-00

Abstract

   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.

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 7 May 2025.

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

Wouters                    Expires 7 May 2025                   [Page 1]
Internet-Draft   Current practices for new cryptography    November 2024

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Historic decisions  . . . . . . . . . . . . . . . . . . . . .   2
   3.  Cryptographic Communities . . . . . . . . . . . . . . . . . .   3
     3.1.  Crypto Forum Research Group (CFRG)  . . . . . . . . . . .   3
     3.2.  Crypto Panel  . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Cryptographically strong Working Groups . . . . . . . . .   4
   4.  Code Points versus RFCs . . . . . . . . . . . . . . . . . . .   4
     4.1.  IANA Registries . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  What cryptography requires an RFC . . . . . . . . . . . .   5
   5.  RECOMMENDED algorithms  . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  TODO  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   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.

2.  Historic decisions

   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

Wouters                    Expires 7 May 2025                   [Page 2]
Internet-Draft   Current practices for new cryptography    November 2024

   [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].

3.  Cryptographic Communities

   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.

3.1.  Crypto Forum Research Group (CFRG)

   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].

Wouters                    Expires 7 May 2025                   [Page 3]
Internet-Draft   Current practices for new cryptography    November 2024

3.2.  Crypto Panel

   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.

3.3.  Cryptographically strong Working Groups

   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.

4.  Code Points versus RFCs

   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.

Wouters                    Expires 7 May 2025                   [Page 4]
Internet-Draft   Current practices for new cryptography    November 2024

4.1.  IANA Registries

   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.

4.2.  What cryptography requires an RFC

   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.

Wouters                    Expires 7 May 2025                   [Page 5]
Internet-Draft   Current practices for new cryptography    November 2024

   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.

5.  RECOMMENDED algorithms

   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.

6.  IANA Considerations

   This document contains no actions for IANA.

7.  Security Considerations

   This document clarifies IETF process on cryptographic algorithms and
   has no specific Security Considerations.

8.  TODO

   How to fit in "clever" crypto inventions, eg PPM?

Wouters                    Expires 7 May 2025                   [Page 6]
Internet-Draft   Current practices for new cryptography    November 2024

   How to fit in combinatorics, hybrid constructions, etc?

9.  Informative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <https://www.rfc-editor.org/info/rfc1321>.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014,
              October 1996, <https://www.rfc-editor.org/info/rfc2014>.

   [RFC3174]  Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
              <https://www.rfc-editor.org/info/rfc3174>.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

   [RFC4357]  Popov, V., Kurepkin, I., and S. Leontiev, "Additional
              Cryptographic Algorithms for Use with GOST 28147-89, GOST
              R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
              Algorithms", RFC 4357, DOI 10.17487/RFC4357, January 2006,
              <https://www.rfc-editor.org/info/rfc4357>.

   [RFC5430]  Salter, M., Rescorla, E., and R. Housley, "Suite B Profile
              for Transport Layer Security (TLS)", RFC 5430,
              DOI 10.17487/RFC5430, March 2009,
              <https://www.rfc-editor.org/info/rfc5430>.

   [RFC5639]  Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
              (ECC) Brainpool Standard Curves and Curve Generation",
              RFC 5639, DOI 10.17487/RFC5639, March 2010,
              <https://www.rfc-editor.org/info/rfc5639>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
              <https://www.rfc-editor.org/info/rfc7539>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

Wouters                    Expires 7 May 2025                   [Page 7]
Internet-Draft   Current practices for new cryptography    November 2024

   [RFC7836]  Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
              Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
              on the Cryptographic Algorithms to Accompany the Usage of
              Standards GOST R 34.10-2012 and GOST R 34.11-2012",
              RFC 7836, DOI 10.17487/RFC7836, March 2016,
              <https://www.rfc-editor.org/info/rfc7836>.

   [RFC8410]  Josefsson, S. and J. Schaad, "Algorithm Identifiers for
              Ed25519, Ed448, X25519, and X448 for Use in the Internet
              X.509 Public Key Infrastructure", RFC 8410,
              DOI 10.17487/RFC8410, August 2018,
              <https://www.rfc-editor.org/info/rfc8410>.

   [RFC8603]  Jenkins, M. and L. Zieglar, "Commercial National Security
              Algorithm (CNSA) Suite Certificate and Certificate
              Revocation List (CRL) Profile", RFC 8603,
              DOI 10.17487/RFC8603, May 2019,
              <https://www.rfc-editor.org/info/rfc8603>.

   [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
              February 2022, <https://www.rfc-editor.org/info/rfc9180>.

Author's Address

   Paul Wouters (editor)
   Aiven
   Email: paul.wouters@aiven.io

Wouters                    Expires 7 May 2025                   [Page 8]