PQShield

kris@amongbytes.com

AWS

kpanos@amazon.com

Cloudflare

bas@cloudflare.com

University of Waterloo

dstebila@uwaterloo.ca

SEC TLS ECDH ECDHE hybrid ML-KEM post-quantum x25519 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.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 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 () 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.

Table of Contents

• .  Introduction
• .  Motivation
• .  Terminology
• .  Negotiated Groups
  • .  Client Share
  • .  Server Share
  • .  Shared Secret
• .  Regulatory Context
• .  Security Considerations
• .  IANA Considerations
  • .  X25519MLKEM768
  • .  SecP256r1MLKEM768
  • .  SecP384r1MLKEM1024
  • .  Obsoleted Supported Groups
• .  References
  • .  Normative References
  • .  Informative References
• Authors' Addresses

Introduction ML-KEM is a key encapsulation mechanism (KEM) defined in . It is designed to withstand cryptanalytic attacks from quantum computers. defines a framework for combining traditional key exchanges with next-generation key exchange in TLS 1.3. The goal of this approach is to provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols. This document applies the framework in to ML-KEM and specifies code points for the hybrid groups.

Motivation This document introduces three new supported groups for Post-Quantum Traditional (PQ/T) hybrid key agreements in TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine ML-KEM with Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) in the manner described in . Any of the hybrid groups specified in this document may be implemented in a FIPS-approved way as discussed in .

• The first group uses X25519 , is widely deployed, and often serves as the most practical choice for a single PQ/T hybrid combiner in TLS 1.3.
• The second group uses secp256r1 (NIST P-256) . This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms.
• The third group uses secp384r1 (NIST P-384) . This group is intended for high-security environments that require FIPS-approved mechanisms with an increased security margin.

Key establishment using NIST curves is outlined in Section 6.1.2.2 of .

Terminology defines "traditional" algorithms as those that are already widely adopted and "next-generation" algorithms as those that are not yet widely adopted, such as post-quantum algorithms. In this document, ECDHE using Curve25519, P-256, or P-384 is considered traditional, while ML-KEM is considered next-generation. also defines a "hybrid" key exchange as the simultaneous use of multiple key exchange algorithms, with their outputs combined to provide security as long as at least one of the component algorithms remains secure, even if the others are compromised. This document uses the term "hybrid" with the same meaning. 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.

Negotiated Groups

Client Share When the X25519MLKEM768 group is negotiated, the client's key_exchange value is the concatenation of the client's ML-KEM-768 encapsulation key and the client's X25519 ephemeral share. The size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519). When the SecP256r1MLKEM768 group is negotiated, the client's key_exchange value is the concatenation of the secp256r1 ephemeral share and ML-KEM-768 encapsulation key. The ECDHE share is the serialized value of the uncompressed ECDHE point representation as defined in . The size of the client share is 1249 bytes (65 bytes for the secp256r1 part and 1184 bytes for ML-KEM). When the SecP384r1MLKEM1024 group is negotiated, the client's key_exchange value is the concatenation of the secp384r1 ephemeral share and the ML-KEM-1024 encapsulation key. The ECDHE share is the serialized value of the uncompressed ECDHE point representation as defined in . The size of the client share is 1665 bytes (97 bytes for the secp384r1 part and 1568 for ML-KEM).

Server Share When the X25519MLKEM768 group is negotiated, the server's key_exchange value is the concatenation of an ML-KEM ciphertext returned from encapsulation to the client's encapsulation key and the server's ephemeral X25519 share. The size of the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519). When the SecP256r1MLKEM768 group is negotiated, the server's key_exchange value is the concatenation of the server's ephemeral secp256r1 share encoded in the same way as the client share and an ML-KEM ciphertext returned from encapsulation to the client's encapsulation key. The size of the server share is 1153 bytes (1088 bytes for the ML-KEM part and 65 bytes for secp256r1). When the SecP384r1MLKEM1024 group is negotiated, the server's key_exchange value is the concatenation of the server's ephemeral secp384r1 share encoded in the same way as the client share and an ML-KEM ciphertext returned from encapsulation to the client's encapsulation key. The size of the server share is 1665 bytes (1568 bytes for the ML-KEM part and 97 bytes for secp384r1). For all groups, the server MUST perform the encapsulation key check described in Section 7.2 of on the client's encapsulation key and abort with an illegal_parameter alert if it fails. For all groups, the client MUST check if the ciphertext length matches the selected group 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. For all groups, both client and server MUST process the ECDHE part as described in , including all validity checks, and abort with an illegal_parameter alert if it fails.

Shared Secret For X25519MLKEM768, the shared secret is the concatenation of the ML-KEM shared secret and the X25519 shared secret. The shared secret is 64 bytes (32 bytes for each part). For SecP256r1MLKEM768, the shared secret is the concatenation of the ECDHE and ML-KEM shared secrets. The ECDHE shared secret is the x-coordinate of the ECDHE shared secret elliptic curve point represented as an octet string as defined in . The size of the shared secret is 64 bytes (32 bytes for each part). For SecP384r1MLKEM1024, the shared secret is the concatenation of the ECDHE and ML-KEM shared secrets. The ECDHE shared secret is the x-coordinate of the ECDHE shared secret elliptic curve point represented as an octet string as defined in . The size of the shared secret is 80 bytes (48 bytes for the ECDHE part and 32 bytes for the ML-KEM part). For all groups, both client and server MUST calculate the ECDHE part of the shared secret as described in , including the all-zero shared secret check for X25519, and abort the connection with an illegal_parameter alert if it fails.

Regulatory Context This section provides informal notes on how the hybrid key agreement mechanisms defined in this document relate to existing NIST guidance on key derivation and hybrid key establishment.

• FIPS-compliance. All groups defined in this document permit FIPS-approved key derivation as per and . NIST Special Publication 800-56Cr2 approves the usage of the HMAC-based Key Derivation Function (HKDF) with two distinct shared secrets, with the condition that the first one is computed by a FIPS-approved key-establishment scheme. FIPS also requires a certified implementation of the scheme, which will remain more ubiquitous for secp256r1 in the coming years. For this reason, the ML-KEM shared secret is placed first in X25519MLKEM768, while the ECDHE shared secret is placed first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. This means that for SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDHE implementation must be certified, whereas the ML-KEM implementation does not require certification. In contrast, for X25519MLKEM768, the ML-KEM implementation must be certified.
• SP800-227 compliance. NIST Special Publication 800-227 provides general guidance on the design and use of key encapsulation mechanisms, including hybrid constructions. The key agreements defined in this document follow the principles described in Section 4.6 of , which discusses the combination of post-quantum and classical key-establishment schemes and the use of approved key combiners. In particular, the shared-secret concatenation and HKDF-based derivation used by TLS 1.3 are consistent with the composite-KEM constructions and key-combiner recommendations outlined in Sections 4.6.1 and 4.6.2 of . Section 4.6.3 of further provides relevant security considerations for hybrid KEM designs underlying the approach used in this document.

Security Considerations The same security considerations as those described in apply to the approach used by this document. The security analysis relies crucially on the TLS 1.3 message transcript, and one cannot assume a similar hybridization is secure in other protocols. includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers. All groups defined in this document use and generate fixed-length public keys, ciphertexts, and shared secrets, which complies with the requirements described in . During ML-KEM encapsulation, encapsulation randomness m is drawn from a random bit generator and encrypted (see , Algorithms 17 and 20); the client, which holds the decapsulation key, then recovers m exactly during decapsulation (see , Algorithm 18). Consequently, any information m carries about the generator's other outputs is also exposed to the client. The disclosure of the output(s) of an insecure random number generator (RNG) when used in TLS can be used in an attack to compromise the state of the insecure RNG itself as described in . The encapsulation randomness m in ML-KEM is an additional place where RNG output is disclosed to an active attacker. Implementers should follow the RBG guidance in and the random number generation guidance in . Implementers can choose to implement mechanisms from for additional protection across sessions. In contrast, the ECDH ephemeral scalars taken from the RNG are never directly disclosed to the peer. However, any passive observer with access to a cryptographically relevant quantum computer (CRQC) can recover the scalar, which is derived directly from RNG output. Regardless, ephemeral scalars should always be generated using a cryptographically secure RNG: for secp256r1 and secp384r1 as required by , and for X25519 as described in ; the guidance in applies here as well. If the same insecure RNG is used by both algorithms, then a disclosure of state by one of the algorithms will also affect the security of the other algorithm.

IANA Considerations Per this document, IANA has registered three new entries in the "TLS Supported Groups" registry, according to the procedures in . These identifiers are to be used with the final version of ML-KEM ratified by NIST, which is specified in .

X25519MLKEM768

Value:

4588 (0x11EC)

Description:

X25519MLKEM768

DTLS-OK:

Y

Recommended:

Y

Reference:

RFC 10024

Comment:

Combining X25519 ECDH with ML-KEM-768

SecP256r1MLKEM768

Value:

4587 (0x11EB)

Description:

SecP256r1MLKEM768

DTLS-OK:

Y

Recommended:

N

Reference:

RFC 10024

Comment:

Combining secp256r1 ECDH with ML-KEM-768

SecP384r1MLKEM1024

Value:

4589 (0x11ED)

Description:

SecP384r1MLKEM1024

DTLS-OK:

Y

Recommended:

N

Reference:

RFC 10024

Comment:

Combining secp384r1 ECDH with ML-KEM-1024

Obsoleted Supported Groups Experimental code points for pre-standard versions of Kyber768 were added to the "TLS Supported Groups" registry as X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft00 (25498). This document obsoletes these entries. For both entries, IANA has modified the Recommended field to 'D', added this document as a reference, and updated the Comment field to "Pre-standards version of Kyber768. Obsoleted by RFC 10024."

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology 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. 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. 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 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. 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. Informative References 23rd USENIX Security Symposium (USENIX Security 14) National Institute of Standards and Technology This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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. 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.

Authors' Addresses PQShield

kris@amongbytes.com

AWS

kpanos@amazon.com

Cloudflare

bas@cloudflare.com

University of Waterloo

dstebila@uwaterloo.ca