What is X25519MLKEM768 in TLS 1.3 and when to use it

X25519MLKEM768 is a hybrid key exchange group for TLS 1.3. It combines classical X25519 elliptic-curve Diffie-Hellman with ML-KEM-768, the module-lattice key encapsulation mechanism standardised in FIPS 203. The two shared secrets are joined into one handshake secret, so an attacker has to break both algorithms to recover session keys. That includes an attacker who records traffic today and tries to decrypt it with a future quantum computer.

For operators of OT and critical infrastructure, the group matters most on long-lived links: telemetry from substations to a cloud historian, remote engineering access, and replication between control centres. This article explains the three standard hybrid groups, when pure ML-KEM is the better choice, how to verify what a connection actually negotiated, and which group fits CNSA 2.0.

What is X25519MLKEM768 in TLS 1.3?

X25519MLKEM768 is a named group in the TLS Supported Groups registry. A client offers it in the ClientHello, and a server selects it to run X25519 and ML-KEM-768 side by side in a single round trip.

It is defined in draft-ietf-tls-ecdhe-mlkem. The draft defines three hybrid key agreement mechanisms for TLS 1.3, X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024, that combine ML-KEM with an ECDHE exchange. The working group document has since been published as RFC 10024. Its construction follows draft-ietf-tls-hybrid-design, where the classical and post-quantum exchanged secrets are concatenated and used in the key schedule.

Mechanically, the handshake has three parts:

• Client share: the concatenation of the client’s ML-KEM-768 encapsulation key and the client’s X25519 ephemeral share.
• Server share: an ML-KEM ciphertext encapsulated to the client’s key, followed by the server’s X25519 share.
• Shared secret: the concatenation of the ML-KEM shared secret and the X25519 shared secret, 64 bytes in total (32 bytes for each part).

In the IANA TLS Supported Groups registry, X25519MLKEM768 has value 4588 (0x11EC) (IETF draft-kwiatkowski-tls-ecdhe-mlkem-03, 2024). In the working group draft it is marked DTLS-OK: Y and Recommended: Y.

What is the difference between X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024?

The three groups differ in the elliptic curve they use, the ML-KEM parameter set and which half has to be FIPS-validated. X25519MLKEM768 is the general default, SecP256r1MLKEM768 suits environments that only allow NIST curves, and SecP384r1MLKEM1024 is the high-assurance option.

FIPS 203 specifies three parameter sets for ML-KEM. In order of increasing security strength and decreasing performance, these are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. They map to security category 1, 3 and 5.

The order of the secrets is about validation, not strength. For SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDH implementation must be certified whereas the ML-KEM implementation does not require certification. In contrast, for X25519MLKEM768, the ML-KEM implementation must be certified. If your edge appliances have a validated P-256 or P-384 module but no validated ML-KEM, that affects which group you can claim as an approved mode.

The registry also still holds legacy codepoints. The document obsoletes X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft00 (25498). Edge devices that were configured during the pre-standard period may still offer only these groups, so include them in your inventory.

Should I use hybrid or pure ML-KEM for TLS connections from the edge?

Use a hybrid group for most edge-to-cloud and remote access traffic. Use pure ML-KEM where a policy explicitly requires it, such as CNSA 2.0 national security systems, and where both endpoints have been tested on it.

The reason for hybrid is to hedge against an immature algorithm. Gorjan Alagic, presenting NIST SP 800-227, summarised it this way: “New stuff sometimes gets broken, so combo stuff so adversary has to break both new and old.” RFC 10024 states that its key agreements follow the principles described in Section 4.6 of NIST-SP-800-227, which discusses the combination of post-quantum and classical key-establishment schemes.

NIST itself is neutral. Dustin Moody of the NIST Cryptographic Technology Group notes that “NIST does not intend to recommend for/against hybrid schemes”, and lists the trade-off: hybrid reduces risks from uncertainty if either is broken but brings more complexity / slower performance.

Pure ML-KEM is specified in draft-ietf-tls-mlkem, which adds new NamedGroups: MLKEM512, MLKEM768, MLKEM1024 and fills in the other side of draft-ietf-tls-hybrid-design. Its argument is simplicity: clean key agreement, no hybrid duplicate shares or mixing and matching logic.

Practical guidance for OT edges

• Retention period drives urgency. Process data, engineering files and credentials that stay sensitive for ten years or more are the main harvest-now, decrypt-later concern. Prioritise those paths first.
• Do not assume every hop terminates TLS. A cloud load balancer that negotiates X25519MLKEM768 with the internet may re-encrypt to the backend with a classical group.
• Many field devices cannot run TLS 1.3 at all. For PLCs and legacy HMIs, protection at the network layer is often more realistic. Quantum Network’s QPN, for example, encrypts at Layer 3 between gateways and uses a hybrid key agreement with ML-KEM from FIPS 203. No software has to be installed on the equipment behind it.

How do I check whether a TLS connection actually negotiated a post-quantum key exchange?

Look at the ServerHello, not the ClientHello. The key_share extension in the ServerHello contains the group the server actually selected. Offering 0x11EC proves nothing if the server picks plain X25519.

A reliable check for edge-to-cloud links:

1. Capture the handshake on the edge side with a protocol analyser. In TLS 1.3 the ServerHello is still unencrypted, so the selected group is visible.
2. Read the selected group in the ServerHello key_share: 0x11EC means X25519MLKEM768. For pure ML-KEM-1024, the CNSA profile uses ML-KEM-1024 {0x0202}.
3. Check the share length. An X25519MLKEM768 server share is 1120 bytes (IETF draft-kwiatkowski-tls-ecdhe-mlkem-03, 2024). A 32-byte share means classical X25519.
4. Watch for a HelloRetryRequest. If the client only sent a classical key share up front, the server has to request a new one. That costs an extra round trip and is a common sign of misconfigured group preferences.
5. Log it on the server. Make sure your TLS terminators record the negotiated group per session. Then you can alert when sessions fall back to classical groups, instead of finding out during a packet capture.

Does hybrid post-quantum TLS slow down the handshake?

Usually only slightly. The main cost is message size, not computation. On constrained or lossy OT links, though, the larger ClientHello can cause fragmentation or problems with middleboxes, and that deserves testing.

The size increase is concrete:

• X25519MLKEM768 client key share: 1216 bytes (IETF draft-kwiatkowski-tls-ecdhe-mlkem-03, 2024).
• X25519MLKEM768 server key share: 1120 bytes (IETF draft-kwiatkowski-tls-ecdhe-mlkem-03, 2024).
• ML-KEM-768 encapsulation key and ciphertext: 1184 and 1088 bytes (RFC 9936, Appendix B).

Compared with a 32-byte X25519 share, this adds a little over 2 KB per full handshake. For OT the operational consequences are:

• ClientHello spanning multiple packets. Older firewalls, protocol-aware proxies and some industrial DPI engines expect a ClientHello in a single segment. Test before rollout.
• Cellular and satellite backhaul. On high-latency links the extra round trip from a HelloRetryRequest costs more than the cryptography. Configure clients to send the hybrid key share in the first flight.
• Session resumption. Long-lived telemetry sessions perform few full handshakes, so the overhead is amortised. Frequent reconnects after link drops increase it.

Rekeying frequency matters too. Network-layer designs often renew keys on a fixed interval rather than per connection. QPN, for example, renews both the classical and the post-quantum handshake every two minutes, and its latency overhead is typically about 1 ms, depending on load and distance.

Which TLS group meets CNSA 2.0 requirements for edge-to-cloud links?

For TLS 1.3, the NSA-authored CNSA 2.0 profile requires pure ML-KEM-1024 (0x0202) from draft-ietf-tls-mlkem. X25519MLKEM768 and SecP256r1MLKEM768 use ML-KEM-768, which is not part of CNSA 2.0.

The profile, draft-becker-cnsa2-tls-profile, is direct: “CNSA 2.0 requires the use of ML-KEM-1024 for key establishment in TLS.” It adds that any algorithm other than ML-KEM-1024 offered by the client MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection. The suite also specifies AES with 256-bit keys, operating in Galois Counter Mode, so TLS_AES_256_GCM_SHA384 rather than the 128-bit suite.

SecP384r1MLKEM1024 is the only hybrid group that uses the CNSA parameter set. It can serve as a transitional option where an organisation’s own policy allows hybrid, but it does not match the TLS profile as written. Note that the profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (NSS). Critical infrastructure operators outside NSS often treat CNSA 2.0 as a benchmark rather than a binding rule. Check which applies to you.

Timeline context

NIST’s proposed transition sets quantum-vulnerable key establishment at 112-bit strength as deprecated after 2030 and disallowed after 2035 (NIST, Dustin Moody, March 2025). OT equipment is often in service for 15 to 20 years, so edge devices bought now will very likely still be running after those dates. Crypto agility, meaning the ability to change the group or algorithm without replacing hardware, belongs on the procurement checklist.