]> Ericsson

Sweden john.mattsson@ericsson.com

Ericsson

Finland sini.ruohomaa@ericsson.com

Security Transport Layer Security tls hqc hybrid This document defines nine quantum-resistant TLS 1.3 key exchange algorithms based on HQC-KEM, the code-based KEM selected by NIST for standardization in forthcoming FIPS 207. Three use HQC-KEM standalone, two combine it with X25519 or X448 in PQ/T hybrids, two combine it with ML-KEM in PQ/PQ hybrids, and two combine it with ML-KEM and X25519 or X448 in PQ/PQ/T hybrids. Because HQC-KEM relies on hardness assumptions and constructions different from those underlying lattice-based ML-KEM, these algorithms provide algorithmic diversity that can mitigate the impact of future cryptanalytic advances or implementation weaknesses in lattice-based cryptography. The algorithms are intended for TLS 1.3, DTLS 1.3, and QUIC, and the hybrid algorithms follow 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 . ML-KEM is the primary post-quantum KEM and is used in TLS 1.3 both standalone and in hybrid key exchange algorithms such as X25519MLKEM768 . ML-KEM is lattice-based, and its security relies on the hardness of the Module Learning With Errors (MLWE) problem. In March 2025, NIST selected HQC (Hamming Quasi-Cyclic) for standardization as a second post-quantum KEM . HQC-KEM is code-based, and its security relies on the hardness of decoding random quasi-cyclic codes. NIST selected HQC to provide a backup to ML-KEM that is based on a different hardness assumption and construction, so that a future cryptanalytic breakthrough against lattice-based cryptography or ML-KEM does not leave deployments without a standardized post-quantum KEM. NIST is specifying HQC-KEM in the forthcoming . In addition to NIST, European cybersecurity agencies have high trust in HQC-KEM. For example, ANSSI labels HQC-KEM as "higher confidence", together with ML-KEM, ML-DSA, and FrodoKEM . HQC-KEM has larger encapsulation keys and ciphertexts and is slower than ML-KEM .

• Editor's note: At the time of writing, FIPS 207 has not been published, not even as an Initial Public Draft. This document is based on the HQC specification of 2026-10-12 . All references to , including section references, parameter set names, and the sizes in , need to be verified and updated once FIPS 207 is published. This note is to be removed before publication as an RFC.

specifies a general design for hybrid key exchange in TLS 1.3. This document applies that design to six hybrid key exchange algorithms and separately defines three standalone key exchange algorithms based on HQC-KEM.

• HQCKEM128, HQCKEM192, and HQCKEM256 use the HQC-KEM parameter sets targeting security categories 1, 3, and 5 , respectively, without any other component. They provide security against quantum attackers as long as HQC-KEM remains secure. Standalone code points are defined for every HQC-KEM parameter set in , consistent with the standalone ML-KEM code points .
• HQCKEM192X25519 and HQCKEM256X448 are PQ/T hybrids that combine HQC-KEM with the traditional elliptic-curve algorithms X25519 and X448 . They provide security against quantum attackers as long as HQC-KEM remains secure and security against classical attackers as long as at least one of the two components remains secure.
• HQCKEM192MLKEM768 and HQCKEM256MLKEM1024 are PQ/PQ hybrids that combine HQC-KEM with ML-KEM . They provide security against quantum attackers as long as at least one of the code-based and lattice-based components remains secure, mitigating the impact of future cryptanalytic advances or implementation weaknesses against either component.
• HQCKEM192MLKEM768X25519 and HQCKEM256MLKEM1024X448 are PQ/PQ/T hybrids that combine HQC-KEM with both ML-KEM and X25519 or X448, respectively. They provide security against quantum attackers as long as at least one of the post-quantum components remains secure, and security against classical attackers as long as at least one of the three components remains secure.

Recent developments have increased interest in algorithmic diversity and conservative key exchange designs. In particular, a claimed polynomial-time quantum algorithm for the Dihedral Coset Problem (DCP) , which was subsequently challenged , prompted discussion about the security of lattice-based cryptography, while recent advances in the cryptanalysis of Goppa codes have challenged long-standing assumptions and led BSI to no longer recommend Classic McEliece for new developments . The algorithms specified in this document provide algorithmic diversity, while the PQ/PQ and PQ/PQ/T hybrids provide a conservative design, with significantly smaller key shares and better performance than FrodoKEM . The algorithms in this document are not intended to replace ML-KEM in latency-sensitive deployments such as the Web. The PQ/PQ and PQ/PQ/T hybrids primarily target high-security deployments where the protected information may need to remain confidential for decades and handshake latency is less critical. The algorithms defined in this document are intended for use with TLS 1.3 , DTLS 1.3 , and QUIC . The hybrid algorithms follow the hybrid key exchange construction defined in , which for the PQ/PQ/T hybrids is applied with three components. This document defines additional TLS NamedGroup values and specifies the encoding of the associated key shares and asymmetric shared secrets, using the terminology of . 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 , hybrid schemes , ML-KEM , and HQC-KEM . In this document, HQC-KEM-128, HQC-KEM-192, and HQC-KEM-256 denote the HQC-KEM parameter sets targeting security categories 1, 3, and 5, respectively. These correspond to the parameter sets named HQC-1, HQC-3, and HQC-5 in .

• Editor's note: Update the parameter set names to match those used in .

This document uses three distinct terms for shared values:

Shared secret key:

The 32-byte output of HQC-KEM and ML-KEM encapsulation and decapsulation, as defined in and . Shared secret keys are computationally indistinguishable from uniformly random bit strings and can be used directly as symmetric keys without additional key derivation.

Shared secret:

The output of the X25519 and X448 functions, as defined in . Shared secrets are encodings of field elements, are easily distinguishable from uniformly random bit strings, and require key derivation before use as keys.

Asymmetric shared secret:

The value produced by the key exchange and used as input to HKDF-Extract in the TLS 1.3 key schedule, from which all traffic keys are derived, see and . The previous specification of TLS 1.3 referred to this value as the (EC)DHE shared secret. For the standalone algorithms in this document, the asymmetric shared secret is the HQC-KEM shared secret key. For the hybrid algorithms, it is the concatenation of the shared secret keys and shared secrets of the components.

HQC-KEM Key Exchange Algorithms This document defines nine TLS NamedGroups for use with the TLS 1.3 supported_groups and key_share extensions. For the hybrid algorithms, key shares and asymmetric shared secrets are encoded by concatenating the component values in the order indicated by the name. All encodings are fixed-length. For all algorithms, the client key_exchange value contains the encapsulation key or public key of each component, and the server key_exchange value contains the ciphertext or public key of each component. The HQC-KEM and ML-KEM shared secret keys are produced by encapsulation and decapsulation as specified in and . The X25519 and X448 shared secrets are produced as specified in .

Sizes summarizes the security category and the sizes in bytes of the client key share, the server key share, and the asymmetric shared secret for each algorithm. Security Categories and Key Share and Asymmetric Shared Secret Sizes in Bytes

NamedGroup	Security category	Client share	Server share	Asymmetric shared secret
HQCKEM128	1	2241	4433	32
HQCKEM192	3	4514	8978	32
HQCKEM256	5	7237	14421	32
HQCKEM192X25519	3	4546	9010	64
HQCKEM256X448	5	7293	14477	88
HQCKEM192MLKEM768	3	5698	10066	64
HQCKEM256MLKEM1024	5	8805	15989	64
HQCKEM192MLKEM768X25519	3	5730	10098	96
HQCKEM256MLKEM1024X448	5	8861	16045	120

All key share sizes are well below the maximum key_exchange length of 2¹⁶ - 1 bytes.

HQCKEM128, HQCKEM192, and HQCKEM256 For HQCKEM128, HQCKEM192, and HQCKEM256, the client key_exchange value contains the HQC-KEM-128, HQC-KEM-192, or HQC-KEM-256 encapsulation key, respectively: The server key_exchange value contains the HQC-KEM ciphertext: The 32-byte asymmetric shared secret input to the TLS 1.3 key schedule is the HQC-KEM shared secret key.

HQCKEM192X25519 For HQCKEM192X25519, the client key_exchange value contains the HQC-KEM-192 encapsulation key followed by the X25519 public key: The server key_exchange value contains the HQC-KEM-192 ciphertext followed by the X25519 public key: The 64-byte asymmetric shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret key followed by the X25519 shared secret:

HQCKEM256X448 For HQCKEM256X448, the client key_exchange value contains the HQC-KEM-256 encapsulation key followed by the X448 public key: The server key_exchange value contains the HQC-KEM-256 ciphertext followed by the X448 public key: The 88-byte asymmetric shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret key followed by the X448 shared secret:

HQCKEM192MLKEM768 For HQCKEM192MLKEM768, the client key_exchange value contains the HQC-KEM-192 encapsulation key followed by the ML-KEM-768 encapsulation key: The server key_exchange value contains the HQC-KEM-192 ciphertext followed by the ML-KEM-768 ciphertext: The 64-byte asymmetric shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret key followed by the ML-KEM shared secret key:

HQCKEM256MLKEM1024 For HQCKEM256MLKEM1024, the client key_exchange value contains the HQC-KEM-256 encapsulation key followed by the ML-KEM-1024 encapsulation key: The server key_exchange value contains the HQC-KEM-256 ciphertext followed by the ML-KEM-1024 ciphertext: The 64-byte asymmetric shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret key followed by the ML-KEM shared secret key:

HQCKEM192MLKEM768X25519 For HQCKEM192MLKEM768X25519, the client key_exchange value contains the HQC-KEM-192 encapsulation key, followed by the ML-KEM-768 encapsulation key, followed by the X25519 public key: The server key_exchange value contains the HQC-KEM-192 ciphertext, followed by the ML-KEM-768 ciphertext, followed by the X25519 public key: The 96-byte asymmetric shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret key, followed by the ML-KEM shared secret key, followed by the X25519 shared secret:

HQCKEM256MLKEM1024X448 For HQCKEM256MLKEM1024X448, the client key_exchange value contains the HQC-KEM-256 encapsulation key, followed by the ML-KEM-1024 encapsulation key, followed by the X448 public key: The server key_exchange value contains the HQC-KEM-256 ciphertext, followed by the ML-KEM-1024 ciphertext, followed by the X448 public key: The 120-byte asymmetric shared secret input to the TLS 1.3 key schedule is the concatenation of the HQC-KEM shared secret key, followed by the ML-KEM shared secret key, followed by the X448 shared secret:

Validation Both client and server MUST check that the received key share has the length given in for the negotiated group and abort with an "illegal_parameter" alert if it fails. The server MUST perform any encapsulation key checks specified in on the client's HQC-KEM encapsulation key and abort with an "illegal_parameter" alert if they fail. For algorithms with an ML-KEM component, the server MUST also perform the encapsulation key check described in Section 7.2 of on the client's ML-KEM encapsulation key and abort with an "illegal_parameter" alert if it fails.

• Editor's note: Add a section reference to the HQC-KEM input checks in , if any are specified.

If HQC-KEM or ML-KEM decapsulation fails for any reason, the client MUST abort with an "internal_error" alert. For algorithms with an X25519 or X448 component, both client and server MUST calculate the X25519 or X448 shared secret as described in , including the check that the shared secret is not the all-zero value, and abort with an "illegal_parameter" alert if it fails.

Implementation Considerations The HQC-KEM decapsulation key is a 32-byte seed. Clients can avoid expanding the seed twice by retaining the expanded key in memory from key generation until the server's key share has been processed.

• Editor's note: The decapsulation key format follows the HQC specification of 2026-10-12 . Update this text if specifies a different format.

Security Considerations The hybrid algorithms defined in this document use the hybrid construction specified in . Their security relies on the TLS 1.3 transcript binding and key schedule. The security considerations in , , , , , and apply to the algorithms defined in this document. A key share, or any of its components, MUST NOT be reused for multiple connections, as required by TLS 1.3 . HQC-KEM-128, HQC-KEM-192, and HQC-KEM-256 target post-quantum security categories 1, 3, and 5 , respectively. All algorithms with HQC-KEM-256 provide security category 5, matching the security level of cipher suites with AES-256 and ChaCha20. HQC-KEM is designed to provide indistinguishability under adaptive chosen-ciphertext attack (IND-CCA2) security . The security of HQC-KEM relies on the hardness of decoding random quasi-cyclic codes, which is a different assumption than the module lattice assumptions underlying ML-KEM. HQC-KEM therefore provides algorithmic diversity for deployments concerned about future cryptanalytic advances against lattice-based cryptography, see . Hybrid constructions also protect against implementation vulnerabilities, such as side-channel leakage or software bugs, in one of the component algorithms. Compared with X25519MLKEM768 , which has the value Y in the Recommended column of the IANA TLS Supported Groups registry , HQCKEM192MLKEM768X25519 and HQCKEM256MLKEM1024X448 provide greater security margin and algorithmic diversity, at the cost of larger messages and higher computational cost. The key share sizes and the computational cost are dominated by the HQC-KEM component. The hybrid key exchange algorithms defined in this document are compatible with the key combiner specified in and the CatKDF key combiner specified in . The security analysis of applies, and all hybrid algorithms retain the security of their strongest component. 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 hybrid key exchange algorithms defined in this document are designed to meet this requirement and preserve the quantum resistance and IND-CCA2 security of HQC-KEM and ML-KEM. X25519 provides approximately 128 bits of classical security and X448 approximately 224 bits of classical security ; neither provides quantum resistance. Compared with P-curves and Brainpool curves offering a comparable security level, X25519 and X448 are significantly faster and provide greater implementation robustness. Deployments that require a traditional component in the key exchange, for example due to regulatory recommendations, should use the PQ/T or PQ/PQ/T hybrids rather than the PQ/PQ hybrids or the standalone algorithms. Note that it is uncertain whether regulators worldwide will continue to approve cryptographic constructions such as PQ/T or PQ/PQ/T hybrids once the traditional component has been deprecated. The algorithms can be combined with an external pre-shared key (PSK) using the TLS 1.3 "psk_dhe_ke" key exchange mode , optionally together with certificate-based authentication . This yields PQ/PSK hybrids without any additional code points. Availability is a fundamental security property and part of the CIA triad in information security . HQC-KEM encapsulation keys and ciphertexts are significantly larger than those of ML-KEM at the same security category. Large client key shares 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. Clients may choose to advertise the groups in this document in the supported_groups extension without sending a corresponding key share in the initial ClientHello, at the cost of an additional round trip if the server selects one of them using HelloRetryRequest. An HQC-KEM ciphertext is roughly twice the size of the encapsulation key, making the server's first flight much larger than the ClientHello. Each transport can pay extra round trips for this. In QUIC, the anti-amplification limit can delay the server's first flight until the client's address is validated. DTLS 1.3 servers SHOULD verify return routability with a HelloRetryRequest cookie () before sending an HQC-KEM ciphertext when the client's address has not otherwise been validated. Implementations MUST NOT use the algorithms defined in this document 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 .

• Editor's note: This requirement will appear in a future version of . Update the reference when published.

Algorithmic Diversity One risk to consider is a novel algorithm that breaks most of lattice-based cryptography, regardless of whether the underlying lattices are structured, as in ML-KEM , or unstructured, as in FrodoKEM . For example, a polynomial-time quantum algorithm for the Dihedral Coset Problem (DCP) would, by Regev's reduction as improved by Brakerski et al. , yield a polynomial-time quantum algorithm for the Learning With Errors (LWE) problem. The best known quantum algorithm for DCP is Kuperberg's subexponential-time algorithm . Claimed polynomial-time quantum algorithms for LWE in 2024 and for DCP in 2026 were subsequently refuted or challenged, but illustrate that this remains an active research area. HQC-KEM relies on the hardness of decoding random quasi-cyclic codes in the Hamming metric, and efficient algorithms for DCP or LWE are not known to imply an efficient decoding algorithm for such codes. Recent advances in the cryptanalysis of Goppa codes have challenged long-standing assumptions and led BSI to no longer recommend the ISO-standardized Classic McEliece for new developments . While HQC-KEM is also code-based like Classic McEliece, its security relies on the hardness of decoding random quasi-cyclic codes and is not affected by advances in cryptanalysis of Goppa codes. The algorithms specified in this document provide algorithmic diversity, and the PQ/PQ and PQ/PQ/T hybrids provide a conservative design. They remain secure against quantum attackers unless both the lattice-based and code-based components are broken. Compared with FrodoKEM , the combination of ML-KEM and HQC-KEM has significantly smaller key shares and requires roughly an order of magnitude fewer CPU cycles at the same security category . These hybrids are particularly well suited to high-security applications where handshake latency is not a primary concern. Nation-state attackers have a long history of recording high-value encrypted traffic and decrypting it later, once better cryptanalytic tools become available. A key exchange therefore has to be chosen at deployment time to provide adequate confidentiality for the entire period during which the protected information remains sensitive, which may be decades. This cannot be fixed afterwards. Traffic recorded before a cryptographic transition remains protected only by the key exchange used at the time, and a single transfer of sensitive data over an inadequately protected connection, such as a backup, can expose all of that data. PQ/T hybrids do not protect against quantum attackers if the post-quantum component is broken, as a quantum attacker can break the traditional component. Robust security against quantum attackers, that is, security that survives the break of a single post-quantum algorithm, requires either a PQ/PQ or PQ/PSK hybrid. Ekerå strongly recommends PQ/PSK hybrids , as the pre-shared key preserves security even if the post-quantum algorithm is broken. However, PQ/PSK hybrids require symmetric keys to be provisioned in advance, which may be impractical in many use cases due to the challenges of key provisioning and trust establishment. Cryptographic agility is the capability to quickly change cryptographic algorithms in response to evolving security requirements or newly discovered vulnerabilities, while maintaining interoperability and system functionality. Supporting both ML-KEM and HQC-KEM enables a system to transition between lattice-based and code-based key establishment. However, agility only protects connections established after the transition, as discussed above. This is why hybrid key establishment, particularly PQ/PQ hybrids, is important for key exchange, but the same rationale does not generally apply to digital signatures. Furthermore, in environments where cryptographic updates are slow, upgrading all legacy nodes can take a decade, so a post-quantum algorithm found to be weak cannot be swapped out quickly. PQ/PQ and PQ/PQ/T hybrids provide an additional security margin here: unlike hybrids with a single post-quantum component, they keep previously protected data confidential against quantum adversaries even if one of the post-quantum components is later broken. ML-KEM and HQC are both structured schemes built on polynomial rings, so a natural concern is that an attack exploiting ring structure might apply to both. The rings, however, differ in essential ways. ML-KEM works over Z_q[X]/(X²⁵⁶ + 1) with q = 3329. This ring splits into 128 quadratic factors, which ML-KEM exploits for fast NTT-based multiplication. Its secrets and errors are small in absolute value, and its security rests on the Module-LWE problem. HQC works over F₂[X]/(Xⁿ − 1), where n is a prime chosen so that Xⁿ − 1 factors only as (X − 1) times a single irreducible polynomial, deliberately limiting exploitable substructure. Its secrets and errors are sparse in Hamming weight, and its security rests on the quasi-cyclic syndrome decoding problem. The two rings therefore differ in characteristic, in how they factor, and in the notion of "small" on which hardness depends. No known attack technique or reduction establishes that an efficient solution to the underlying problem of one scheme would yield an efficient attack on the other.

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

HQCKEM128

Value:

TBD1

Description:

HQCKEM128

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

Standalone HQC-KEM-128

HQCKEM192

Value:

TBD2

Description:

HQCKEM192

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

Standalone HQC-KEM-192

HQCKEM256

Value:

TBD3

Description:

HQCKEM256

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

Standalone HQC-KEM-256

HQCKEM192X25519

Value:

TBD4

Description:

HQCKEM192X25519

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

PQ/T hybrid combining HQC-KEM-192 with X25519

HQCKEM256X448

Value:

TBD5

Description:

HQCKEM256X448

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

PQ/T hybrid combining HQC-KEM-256 with X448

HQCKEM192MLKEM768

Value:

TBD6

Description:

HQCKEM192MLKEM768

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

PQ/PQ hybrid combining HQC-KEM-192 with ML-KEM-768

HQCKEM256MLKEM1024

Value:

TBD7

Description:

HQCKEM256MLKEM1024

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

PQ/PQ hybrid combining HQC-KEM-256 with ML-KEM-1024

HQCKEM192MLKEM768X25519

Value:

TBD8

Description:

HQCKEM192MLKEM768X25519

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

PQ/PQ/T hybrid combining HQC-KEM-192 with ML-KEM-768 and X25519

HQCKEM256MLKEM1024X448

Value:

TBD9

Description:

HQCKEM256MLKEM1024X448

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

PQ/PQ/T hybrid combining HQC-KEM-256 with ML-KEM-1024 and X448

References Normative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology 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. 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 HQC Team National Institute of Standards and Technology (U.S.) NIST Workshop on Guidance for KEMs Society for Industrial & Applied Mathematics (SIAM) Springer International Publishing Society for Industrial & Applied Mathematics (SIAM) Cryptology ePrint Archive, Paper 2024/555 Cryptology ePrint Archive, Paper 2026/1591 Cryptology ePrint Archive, Paper 2026/1693 French Cybersecurity Agency (ANSSI) Federal Office for Information Security (BSI) ISO/IEC National Institute of Standards and Technology National Institute of Standards and Technology ETSI 3GPP 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. 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 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. This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC obsoletes RFC 8773, which was an Experimental RFC. 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. NIS Cooperation Group NIS Cooperation Group Swedish NCSC n.d.

Acknowledgments The authors thank the authors of previous drafts from which this draft borrowed text. The authors thank Ciarán Mullan and Angela Robinson for their valuable comments and feedback on this draft.