]> Zscaler

yrosomakho@zscaler.com

Security Transport Layer Security tls mlkem hybrid 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. 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 The transition to post-quantum cryptography requires new key exchange mechanisms for TLS 1.3 . Hybrid key exchange combines a post-quantum key encapsulation mechanism with a traditional elliptic-curve Diffie-Hellman key exchange, allowing deployments to gain protection against future cryptographically relevant quantum computers while retaining the security properties of widely deployed classical key exchange mechanisms. describes the general design for hybrid key exchange in TLS 1.3, and defines several ECDHE-MLKEM hybrid groups based on ML-KEM-768 and ML-KEM-1024. This document defines two additional ECDHE-MLKEM hybrid groups that use ML-KEM-512:

• MLKEM512X25519
• SecP256r1MLKEM512

This document follows the construction and terminology of . It defines only additional TLS NamedGroup values and their associated key share encodings. It does not modify the TLS 1.3 handshake, key schedule, or negotiation mechanisms.

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. This document uses the terminology of TLS 1.3 and hybrid key exchange for TLS 1.3 . The term "ML-KEM" refers to the Module-Lattice-Based Key-Encapsulation Mechanism defined in .

Motivation and Applicability The ECDHE-MLKEM hybrid groups defined in are appropriate for general-purpose post-quantum hybrid deployments and provide higher post-quantum security categories than ML-KEM-512. However, the use of ML-KEM-768 or ML-KEM-1024 increases the size of TLS key shares. Larger key shares increase the size of TLS handshake messages. In particular, larger client key shares increase the size of the ClientHello, which can increase the likelihood of fragmentation and may expose interoperability problems in deployments involving legacy network devices, middleboxes, or other network infrastructure with limitations around larger TLS ClientHello messages. Larger key shares can also increase bandwidth, memory, and computational costs for constrained endpoints or for deployments operating over lossy or bandwidth-constrained networks. The groups defined in this document use ML-KEM-512 in combination with classical ECDHE key exchange. This provides hybrid post-quantum and classical key exchange with lower bandwidth, memory, and computational overhead than corresponding hybrid groups based on ML-KEM-768 or ML-KEM-1024. The following table shows the key share sizes for the groups defined in this document:

Group	Client key share size	Server key share size
MLKEM512X25519	832 bytes	800 bytes
SecP256r1MLKEM512	865 bytes	833 bytes

ML-KEM-512 provides a lower post-quantum security category than ML-KEM-768 and ML-KEM-1024. Deployments that can support hybrid groups based on ML-KEM-768 or ML-KEM-1024 SHOULD generally prefer those groups. The groups defined in this document are intended for constrained, compatibility-sensitive, bandwidth-sensitive, or otherwise policy-selected deployments.

Hybrid Group Definitions This document defines two additional TLS NamedGroup values for use with the TLS 1.3 key_share extension:

• MLKEM512X25519
• SecP256r1MLKEM512

Each group combines an ML-KEM-512 key exchange with an elliptic-curve Diffie-Hellman key exchange. The hybrid key exchange values are encoded as the concatenation of the component key exchange values. The component encodings are fixed length and are therefore unambiguous. For ML-KEM-512, the encapsulation key and ciphertext are encoded as defined in . The ML-KEM-512 encapsulation key is 800 octets, and the ML-KEM-512 ciphertext is 768 octets. For X25519 and secp256r1, the public key encodings used in the key_share extension are those defined in . The X25519 public key is the 32-octet public value for X25519 defined in . The secp256r1 public key is encoded as the UncompressedPointRepresentation and is 65 octets. The server MUST perform the encapsulation key check described in Section 7.2 of on the client's ML-KEM-512 encapsulation key and abort with an illegal_parameter alert if it fails. The client MUST check that the ML-KEM-512 ciphertext length is 768 octets and abort with an illegal_parameter alert if it fails. If ML-KEM decapsulation fails for any other reason, the connection MUST be aborted with an internal_error alert. Both client and server MUST process the ECDHE component as described in , including all validity checks, and abort with an illegal_parameter alert if it fails.

MLKEM512X25519 For MLKEM512X25519, the client key_exchange value contains the ML-KEM-512 encapsulation key followed by the X25519 public key: The server key_exchange value contains the ML-KEM-512 ciphertext followed by the X25519 public key: The name MLKEM512X25519 reflects the order of the component algorithms in the NamedGroup definition. This is the ordering convention specified by , which requires the order of shares in the concatenated key_exchange value to match the order of algorithms indicated in the definition of the NamedGroup. Accordingly, the ML-KEM-512 component appears first in both the name and the encoded key_exchange value, followed by the X25519 component. This differs from the name X25519MLKEM768 defined in . That name is retained for historical compatibility reasons and is explicitly documented by as not following the naming convention in . This document follows the convention from for the new MLKEM512X25519 NamedGroup.

SecP256r1MLKEM512 For SecP256r1MLKEM512, the client key_exchange value contains the secp256r1 ECDHE public key followed by the ML-KEM-512 encapsulation key: The server key_exchange value contains the secp256r1 ECDHE public key followed by the ML-KEM-512 ciphertext: The component order for SecP256r1MLKEM512 follows the convention used by for NIST elliptic curves.

Shared Secret Calculation For each group defined in this document, the hybrid shared secret is the concatenation of the component shared secrets. The resulting hybrid shared secret is used as the ECDHE shared secret input to the TLS 1.3 key schedule. For MLKEM512X25519, the ML-KEM shared secret is produced by ML-KEM-512 encapsulation and decapsulation, and the X25519 shared secret is produced by the X25519 Diffie-Hellman operation. The hybrid shared secret is the concatenation of the ML-KEM shared secret followed by the X25519 shared secret: The ML-KEM-512 shared secret is 32 octets, and the X25519 shared secret is 32 octets. The resulting hybrid shared secret is therefore 64 octets. For SecP256r1MLKEM512, the ECDHE shared secret is produced by the secp256r1 Diffie-Hellman operation, and the ML-KEM shared secret is produced by ML-KEM-512 encapsulation and decapsulation. The hybrid shared secret is the concatenation of the ECDHE shared secret followed by the ML-KEM shared secret: The secp256r1 shared secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string, as described in . The secp256r1 shared secret is 32 octets, and the ML-KEM-512 shared secret is 32 octets. The resulting hybrid shared secret is therefore 64 octets. Both client and server MUST calculate the ECDHE component of the shared secret as described in , including the all-zero shared secret check for X25519. If this computation or validation fails, the endpoint MUST abort the connection with an illegal_parameter alert.

Regulatory Context The regulatory considerations related to component ordering and the use of hybrid ECDHE-MLKEM key exchange are discussed in and apply to the groups defined in this document.

Security Considerations The security considerations outlined in and apply to the groups defined in this document. This document defines additional ECDHE-MLKEM hybrid groups and does not change the TLS 1.3 handshake, key schedule, authentication mechanisms, or the general hybrid key exchange construction. The groups defined in this document use ML-KEM-512. ML-KEM-512 provides a lower post-quantum security category than ML-KEM-768 and ML-KEM-1024. As a result, the groups defined in provide stronger post-quantum security properties and are generally preferred when their larger key shares and implementation costs are acceptable. The groups defined in this document are intended for constrained, compatibility-sensitive, bandwidth-sensitive, or otherwise policy-selected deployments where the lower overhead of ML-KEM-512 is considered an acceptable trade-off.

IANA Considerations This document requests/registers two new entries to the TLS Supported Groups registry, according to the procedures in .

MLKEM512X25519

Value:

4586 (0x11EA)

Description:

MLKEM512X25519

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

Combining ML-KEM-512 with X25519 ECDH

SecP256r1MLKEM512

Value:

4585 (0x11E9)

Description:

SecP256r1MLKEM512

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

Combining secp256r1 ECDH with ML-KEM-512

References Normative References National Institute of Standards and Technology (U.S.) Independent 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, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. University of Waterloo Cisco Systems University of Haifa and Meta 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 transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. PQShield AWS Cloudflare University of Waterloo This draft 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 (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. 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. Informative References 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.

Acknowledgments The author thanks the authors and contributors of and , whose work this document builds on.