]> Cloudflare

bas@cloudflare.com

Security Transport Layer Security This document recommends X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 for use in TLS by updating their entries in the TLS Supported Groups registry (previously EC Named Curve Registry) to Recommended in the light of the future arrival of cryptographically relevant quantum computers. [[ NOTE I use key share in the title and here as it's more accurate than "group" and perhaps more well known in the context TLS than key agreement or key exchange. ]] About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction A future cryptographically relevant quantum computer (CRQC) can decrypt TLS handshakes recorded today that do not use post-quantum algorithms for their key shares: algorithms designed to be resistant against quantum attack. This threat is known as "harvest now, decrypt later" (HNDL) . To address this threat, this document updates the TLS Supported Groups registry to mark the post-quantum key shares X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 as Recommended (Y) as defined in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Security Considerations Before the arrival of a cryptographically relevant quantum computer (CRQC), a TLS connection that negotiated a non-post quantum key share can be recorded decrypted in the future. After the arrival of a CRQC, allowing a non-post quantum key share to be negotiated allows for an active quantum attack that achieves MITM, even if the server certificate is post quantum.

IANA Considerations This document updates the TLS Supported Groups registry, according to the procedures in as follows.

Value	Description	Recommended
4587	SecP256r1MLKEM768	Y
4588	X25519MLKEM768	Y
4589	SecP384r1MLKEM1024	Y

References Normative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This document updates the changes to the TLS and DTLS IANA registries made in RFC 8447. It adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. Nokia Nokia Nokia DigiCert Entrust Limited The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms.