Post-quantum QUIC HTTP/3 ML-KEM: how does it work?

Post-quantum QUIC means running QUIC (RFC 9000) with a TLS 1.3 handshake (RFC 9001) that negotiates a hybrid key exchange such as X25519MLKEM768. That group combines classical X25519 with ML-KEM from FIPS 203. HTTP/3 (RFC 9114) runs on QUIC, so it gets the same protection against traffic that is recorded today and decrypted once quantum computers can do it.

For operators of OT and critical infrastructure, the question is practical: can HTTP/3 links between edge devices, remote sites and your own data centre use ML-KEM today, and what breaks when you try? This article covers the protocol mechanics, the failure modes and the limits for industrial traffic.

Does QUIC support hybrid ML-KEM key exchange?

Yes. QUIC uses the TLS 1.3 handshake for key establishment, so any TLS 1.3 key exchange group, including the hybrid X25519MLKEM768 group, works in QUIC without changing the transport protocol.

RFC 9001 does not define its own cryptography. It carries TLS 1.3 handshake messages inside QUIC CRYPTO frames. The hybrid design in RFC 9954 (Hybrid Key Exchange in TLS 1.3) treats each combination of a classical and a post-quantum algorithm as a single new “named group”. That group is negotiated through the normal supported_groups and key_share extensions. RFC 10024 then defines the concrete groups X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. IETF drafts that build on RFC 9954 explicitly list QUIC (RFC 9001) next to TLS 1.3 and DTLS 1.3 as target protocols.

In X25519MLKEM768 the client sends an ML-KEM-768 encapsulation key plus an X25519 public value. The server answers with an ML-KEM ciphertext plus its own X25519 value. Both shared secrets go into the TLS key schedule, so the session stays confidential as long as either algorithm holds. RFC 10024 also requires the server to run the encapsulation key check from FIPS 203 on the client’s key and to abort if the check fails.

Why do large ML-KEM key shares cause problems with the QUIC anti-amplification limit?

ML-KEM key shares are dozens of times larger than X25519 shares. The ClientHello gets bigger and so does the server’s first flight, and the server’s first flight is capped by QUIC’s address validation rules.

RFC 9000 says that before a server has validated the client’s address, it must not send more than three times as many bytes as it has received. This prevents QUIC servers from being used to reflect traffic at spoofed addresses. It also caps how much handshake data the server can push before the client replies.

Two things change with X25519MLKEM768. First, the ClientHello alone is larger than a single 1200-byte Initial datagram, so it is split across two or more Initial packets. That raises the server’s budget, because the limit grows with every byte received. But it also means the handshake depends on both datagrams arriving, and on middleboxes not dropping fragmented or unusually large UDP datagrams. Second, the server’s first flight has to carry the ServerHello with its larger share plus the certificate chain and CertificateVerify. If that flight exceeds three times what the client sent, the server stops and waits for the client’s next packet, and the handshake gains a round trip.

Does a post-quantum QUIC handshake take an extra round trip compared to TCP with TLS 1.3?

Normally no. RFC 9954 explicitly lists “no extra round trips” as a design goal. A full QUIC handshake still takes one round trip before application data, while TCP with TLS 1.3 needs one for TCP and one for TLS.

Extra round trips do appear in three specific situations:

The HelloRetryRequest case matters most in mixed fleets. If the edge client only sends a speculative X25519 share and the server insists on the hybrid group, every connection pays one extra round trip. The fix is to have clients send the X25519MLKEM768 share directly in their first ClientHello.

How do I enable X25519MLKEM768 for HTTP/3 between edge devices and my own data centre?

Turn the hybrid group on at both ends, make it the preferred group, and then check on the wire that it is actually negotiated over both QUIC and TCP.

1. Check library support on both sides. The TLS library in the edge device’s QUIC stack and the one on your data centre endpoint must both implement ML-KEM and the X25519MLKEM768 group (IANA codepoint 0x11EC). On embedded Linux this is often the deciding factor, because firmware may ship an older TLS library.
2. Set the group order. On the server, list X25519MLKEM768 first and X25519 second. On clients, send the X25519MLKEM768 key share in the first ClientHello to avoid HelloRetryRequest round trips.
3. Check the datagram path. Cellular and satellite backhaul often has a smaller MTU, and some carriers handle UDP differently. Make sure Initial datagrams of at least 1200 bytes pass end to end and are not fragmented or dropped.
4. Trim the server’s first flight. Use short certificate chains, preferably from an internal CA for machine-to-machine traffic, so the server stays within the anti-amplification budget.
5. Advertise HTTP/3 the controlled way. RFC 9114 clients usually discover HTTP/3 through an Alt-Svc header received over TCP. For fixed edge devices it is more predictable to configure HTTP/3 directly.
6. Log the negotiated group. Record the negotiated key exchange group per connection on the server. That is the only reliable way to show that edge traffic is actually post-quantum protected.

Note that this protects key establishment only. Certificates and signatures stay classical until ML-DSA certificates become practical in your PKI. That order matches NIST’s guidance: because of “harvest now, decrypt later”, NIST suggests prioritising FIPS 203 for data that is sensitive or must stay secret for a long time.

What happens when a firewall blocks UDP 443 and QUIC falls back to TCP with post-quantum TLS?

The client quietly falls back to HTTP/2 or HTTP/1.1 over TCP with TLS 1.3. The connection is only quantum-safe if the TCP listener negotiates X25519MLKEM768 as well.

This silent downgrade is the most common gap in practice. Many IT and OT firewalls block or rate-limit UDP 443 by default, partly because they cannot inspect QUIC traffic. Browsers and HTTP clients are designed to recover transparently, so nobody notices the switch. The TCP path is often terminated by a different component (a load balancer, a reverse proxy or an older TLS terminator) than the QUIC path, and that component may still offer only classical X25519.

The fallback itself costs an extra TCP round trip and brings back head-of-line blocking. Those are performance issues. The security issue is the configuration drift between the two paths. Practical steps:

• Configure the TLS group list once and apply it to the QUIC and TCP listeners together.
• Test both paths on purpose: block UDP 443 in a test segment and check the negotiated group on the TCP connection.
• Alert on any connection from a known edge device that negotiates a group without ML-KEM.

Is QUIC suitable for quantum-safe industrial telemetry from remote sites?

For telemetry that is already HTTP-based, such as REST or event streams from modern edge gateways, QUIC works well. Most OT traffic does not run on HTTP/3, though, so on its own QUIC covers only part of a site’s data flows.

QUIC has real advantages on remote links. Independent streams avoid head-of-line blocking when packets are lost. Connection IDs let a session survive NAT rebinding on cellular backhaul. Post-quantum key exchange costs no extra round trip in the normal case. Keep 0-RTT for idempotent data such as periodic readings, because 0-RTT data can be replayed. Never send control commands that way.

The limits are structural. Modbus/TCP, DNP3, IEC 60870-5-104 and much OPC UA traffic run over their own TCP or UDP transports, and PLCs or RTUs cannot run a QUIC stack. Putting these protocols on HTTP/3 means protocol conversion at every site, and every converter adds something to maintain and to secure. Firewalls in OT zones often block UDP as well, which takes you back to the fallback issue above.

That is why many operators keep application-level post-quantum TLS for the HTTP-based parts and protect the site links themselves at the network layer. A Layer 3 approach, such as the Quantum Network QPN gateway, encrypts everything above Layer 3 between sites, including OT protocols, with a hybrid key agreement that combines a classical part with ML-KEM, and without installing software on the equipment behind it. The two approaches complement each other: HTTP/3 with X25519MLKEM768 protects individual sessions end to end, and a network-layer tunnel covers the protocols that will never speak QUIC.

How urgent is the move to ML-KEM for OT operators?

Urgent enough to start now. OT assets often run for decades, and data intercepted today can be decrypted later, so planning horizons are well past the deadlines that regulators and standards bodies have set.

• 2030 to 2040: the period in which experts expect quantum computers could break many common algorithms, according to the Dutch AIVD and NCSC (NCSC-NL, 25 March 2024).
• 31 December 2030: the deadline by which US federal high value assets and high impact systems must adopt post-quantum key establishment (NIST IR 8547, 2026).
• 2035: the year after which NIST will disallow quantum-vulnerable public-key cryptography under its standards and guidelines, after deprecating it after 2030 (NIST IR 8547, 2026).

When FIPS 203 was released, NIST’s Dustin Moody, who heads the PQC standardization project, said: “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.” The AIVD and NCSC put it just as plainly: “Organizations should act now and prepare to make the switch to quantum-secure cryptography.”

Moody has also stressed that “there’s not one strategy that fits all use cases”. For OT that means a mix: X25519MLKEM768 on HTTP/3 and TLS endpoints that support it, configured the same way on the TCP fallback, plus network-layer protection for the industrial protocols underneath.