]> Ericsson

Sweden john.mattsson@ericsson.com

Ericsson

Finland sini.ruohomaa@ericsson.com

Security Transport Layer Security tls mlkem hybrid This document defines a post-quantum/traditional hybrid key exchange algorithm for TLS 1.3 that combines ML-KEM-1024 with X448: MLKEM1024X448. The algorithm provides a hybrid key exchange option targeting a higher security level than X25519MLKEM768, matching the security level of AES-256 and ChaCha20. A large security margin can protect against future cryptanalytic advances, misuse, and implementation errors. Compared with P-curves offering a similar security level, X448 is significantly faster and provides greater implementation robustness. A FIPS-validated implementation of MLKEM1024X448 ensures that the ML-KEM-1024 component is FIPS-validated. The algorithm defined in this document is intended for use with TLS 1.3, DTLS 1.3, and QUIC and follows the general hybrid key exchange construction defined for TLS 1.3.

Introduction The transition to post-quantum cryptography requires new key exchange mechanisms for TLS 1.3 . Post-Quantum/Traditional (PQ/T) hybrid key exchange combines a post-quantum key exchange algorithm such as ML-KEM with a traditional key exchange algorithm such as X448 , allowing deployments to gain protection against future Cryptanalytically Relevant Quantum Computers (CRQC) while retaining the security of previously trusted traditional key exchange algorithms. specifies a general design for hybrid key exchange in TLS 1.3. , , and apply this design to define PQ/T hybrid key exchange algorithms based on ML-KEM. defines standalone TLS 1.3 key exchange algorithms based on ML-KEM. This document applies the hybrid key exchange design specified in to define MLKEM1024X448, a PQ/T hybrid key exchange algorithm for TLS 1.3 that combines ML-KEM-1024 with X448. The algorithm provides a hybrid key exchange option targeting security category 5 , matching the security level of AES-256 and ChaCha20 and providing a higher security level than X25519MLKEM768 . A large security margin can protect against future cryptanalytic advances, misuse, and implementation errors. Compared with P-curves offering a similar security level, X448 is significantly faster and provides greater implementation robustness. A FIPS-validated implementation of MLKEM1024X448 ensures that the ML-KEM-1024 component is FIPS-validated. This is not necessarily the case for SecP384r1MLKEM1024 , where only the secp384r1 component might be FIPS-validated while the ML-KEM-1024 component is not. The algorithm defined in this document is intended for use with TLS 1.3 , DTLS 1.3 , and QUIC and follows the hybrid key exchange construction defined in . It defines only an additional TLS NamedGroup value and its associated key share and shared secret encodings. It does not modify the TLS 1.3 handshake, key schedule, or negotiation mechanisms.

Terminology 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. This document uses the terminology of TLS 1.3 , hybrid key exchange in TLS 1.3 , and ML-KEM .

The MLKEM1024X448 Key Exchange Algorithm This document defines the TLS NamedGroup MLKEM1024X448 for use with the TLS 1.3 supported_groups and key_share extension. Key shares and shared secrets are encoded by concatenating the component values in the order indicated by the name. All encodings are fixed-length.

Client and Server Key Shares For MLKEM1024X448, the client key_exchange value contains the ML-KEM-1024 encapsulation key followed by the X448 public key: The server key_exchange value contains the ML-KEM-1024 ciphertext followed by the X448 public key: Both client and server MUST check that the received key share is 1624 bytes and abort with an "illegal_parameter" alert if it fails. The server MUST perform the encapsulation key check described in Section 7.2 of on the client's ML-KEM-1024 encapsulation key and abort with an "illegal_parameter" alert if it fails. If ML-KEM decapsulation fails for any reason, the client MUST abort with an "internal_error" alert.

Shared Secret For MLKEM1024X448, the 32-byte ML-KEM shared secret is produced by ML-KEM-1024 encapsulation and decapsulation as specified in , and the 56-byte X448 shared secret is produced as specified in by the X448 Diffie-Hellman operation. The 88-byte asymmetric shared secret input to the TLS 1.3 key schedule is the concatenation of the ML-KEM shared secret followed by the X448 shared secret: Both client and server MUST calculate the X448 part of the shared secret as described in , including the all-zero shared secret check, and abort with an "illegal_parameter" alert if it fails.

Security Considerations MLKEM1024X448 uses the hybrid construction specified in . Its security relies on the TLS 1.3 transcript binding and key schedule. The security considerations in , , , , , and apply to the algorithm defined in this document. An MLKEM1024X448 key share, or any of its components, MUST NOT be reused for multiple connections, as required by TLS 1.3 . ML-KEM-1024 provides the highest security among the ML-KEM parameter sets defined in , namely post-quantum security category 5 , matching the security level of AES-256 and ChaCha20. X448 provides approximately 224 bits of classical security and no quantum resistance. Compared with P-curves offering a comparable security level, X448 is significantly faster and provides greater implementation robustness. Compared with X25519MLKEM768 , which has the value Y in the Recommended column of the IANA TLS Supported Groups registry , MLKEM1024X448 provides a higher security level at the cost of moderately larger messages and higher computational cost. As with X25519MLKEM768, the key share sizes are dominated by the ML-KEM component and the computational cost is dominated by the ECDHE component. ML-KEM-1024, with its security category 5, provides a larger security margin than ML-KEM-768, which can protect against future advances in lattice cryptanalysis, as well as misuse and implementation errors. A fundamental requirement of hybrid constructions is that their security is at least as high as that of their strongest component; that is, the construction preserves the cryptographic security properties of its components , , , . The PQ/T hybrid key exchange algorithm defined in this document is designed to meet this requirement. In particular, it preserves the quantum-resistance and indistinguishability under adaptive chosen-ciphertext attack (IND-CCA2) security of ML-KEM . Similar to X25519MLKEM768 and MLKEM512X25519 , a FIPS-validated implementation of MLKEM1024X448 guarantees that the ML-KEM component is FIPS-validated. This is not the case for SecP256r1MLKEM768 and SecP384r1MLKEM1024 , whose primary design goal was to enable vendors to sell existing FIPS-validated implementations of P-256 and P-384 as "quantum-resistant", even though only the quantum-vulnerable components are FIPS validated. FIPS-validated implementations of SecP256r1MLKEM768 and SecP384r1MLKEM1024 might already be disallowed by 2030 . Users seeking a FIPS-validated key exchange in TLS should use FIPS-validated ML-KEM. Availability is a fundamental security property and part of the CIA triad in information security . Large client key shares, such as the 1624-byte MLKEM1024X448 key share, are known to cause interoperability problems with non-compliant or buggy legacy TLS implementations, as well as with middleboxes and other network infrastructure that impose non-compliant limitations on large TLS ClientHello messages. Large key shares also increase bandwidth, memory, and computational costs for constrained endpoints or deployments operating over lossy or bandwidth-constrained networks, potentially reducing availability. Implementations MUST NOT use MLKEM1024X448 with TLS 1.2 or DTLS 1.2, which are obsolete and should be phased out as soon as possible. 3GPP already mandates that TLS 1.2 be disabled by default.

IANA Considerations This document requests that IANA register one new entry in the TLS Supported Groups registry , according to the procedures in .

MLKEM1024X448

Value:

TBD

Description:

MLKEM1024X448

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

PQ/T hybrid combining ML-KEM-1024 with X448

References Normative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. 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 obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. 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. Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by the transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange. 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 National Institute of Standards and Technology National Institute of Standards and Technology Selkie Cryptography This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. Zscaler This document defines two post-quantum hybrid key exchange groups for TLS 1.3 that combine ML-KEM-512 with ECDHE: MLKEM512X25519 and SecP256r1MLKEM512. These groups provide lower-overhead hybrid key exchange options for deployments where ClientHello size, fragmentation risk, constrained-device performance, or compatibility with existing network infrastructure are important considerations. The groups defined in this document are intended for use with TLS 1.3 and DTLS 1.3 and follow the hybrid key exchange construction used by ECDHE-MLKEM key agreement for TLS 1.3. Lenovo Wuhan University Infosec Goodix This document specifies how to form a hybrid key exchange with CurveSM2 and MLKEM in Transport Layer Security (TLS) protocol version 1.3. Related IETF drafts include [hybrid] and [ecdhe-mlkem]. n.d.

Acknowledgments The authors thank the authors of previous drafts from which this draft borrowed text. The authors thank someone for their valuable comments and feedback on this draft.