← Back to Blog Security

QUIC and PQC: How HTTP/3 Got Quantum-Safe

11 min read

QUIC is the transport protocol underneath HTTP/3. It was designed by Google, hardened through real-world deployment, and standardized at IETF in RFC 9000 in 2021. Today it carries a substantial fraction of all web traffic. Major browsers use it, major CDNs serve it, and most modern apps that talk to a backend over the public internet end up using QUIC for at least some connections.

QUIC fixed many problems that TCP had baked in: head-of-line blocking, slow connection establishment, slow connection migration when a mobile device changes networks. But by running over UDP instead of TCP, QUIC inherited a UDP-specific problem when it came time to migrate to post-quantum cryptography: packet size limits.

This blog post explains how QUIC's PQC migration works, what makes it harder than TCP-based TLS migration, and what the practical solutions look like.

Why UDP Makes PQC Harder

TLS over TCP has no inherent packet size constraint. Inside a TCP connection, the operating system handles segmentation transparently. A ClientHello message that is 5 KB might be split across four TCP segments, but the receiver reassembles them into a single message before the TLS layer ever sees it.

UDP has no such reassembly. Each UDP datagram is independent. If a sender sends a 5 KB UDP datagram, IP fragmentation kicks in (or the datagram is dropped, depending on path MTU). IP fragmentation is operationally fragile: many firewalls drop fragmented IPv4 packets entirely, and IPv6 disallows fragmentation by routers in the first place.

QUIC works around UDP's limits by defining its own framing inside UDP. A single QUIC connection sends a stream of UDP datagrams; each datagram carries one or more QUIC packets; each packet carries QUIC frames. The frames can be reassembled at the QUIC layer, which is what enables QUIC to handle large data flows.

But there is one place where this reassembly does not help: the very first packet. The QUIC Initial packet must contain enough information to set up the connection, and it has a strict size constraint: RFC 9000 requires client Initial packets to be at least 1,200 bytes (padded if necessary), and staying near that size is what traverses the largest set of network paths reliably before path MTU discovery. RFC 9000 specifies the minimum to defeat amplification attacks (where an attacker spoofs a small packet to get a large response).

A pre-PQC TLS ClientHello easily fits in 1,200 bytes. A hybrid PQC ClientHello does not.

The Hybrid PQC ClientHello Size Problem

We covered the TLS 1.3 hybrid handshake in detail. Briefly: a X25519MLKEM768 key share inside a ClientHello adds roughly 1,184 bytes for the ML-KEM-768 public key, on top of the existing ~32 bytes for the X25519 public key.

Combined with the rest of the ClientHello (signature algorithms, server name indication, ALPN, supported versions, supported groups list, cookie if any, and so on), a typical hybrid ClientHello lands around 1,700–2,000 bytes.

Compare that to QUIC's 1,200-byte Initial packet limit. The math does not work. The ClientHello must span multiple QUIC packets.

CRYPTO Frames And Reassembly

QUIC carries TLS handshake messages in CRYPTO frames. A CRYPTO frame can be split across multiple QUIC packets, with each fragment carrying an offset that lets the receiver reassemble the full message.

For a 2 KB ClientHello, the client sends two QUIC Initial packets, each containing part of the ClientHello in a CRYPTO frame. The server's QUIC stack reassembles them and hands the complete ClientHello to the TLS state machine.

In principle, this is straightforward. In practice, it added several years of deployment debugging:

Some QUIC implementations did not support multi-packet ClientHellos at all.
Some load balancers terminated QUIC connections expecting a one-packet ClientHello and broke when receiving multiple.
Anti-DDoS appliances that look at QUIC traffic sometimes dropped the second Initial packet, thinking it was redundant.
Path MTU mismatches caused some clients to send packets that fit on the local network but were dropped upstream.

The IETF QUIC WG has tracked these issues through the quicwg mailing list and through draft updates. The current state (late 2025) is that all major QUIC implementations (Google's quiche, Microsoft's msquic, Cloudflare's quiche, ngtcp2, lsquic, Mozilla's neqo) handle multi-packet ClientHellos correctly.

Path MTU And The 1,200-Byte Floor

QUIC's 1,200-byte minimum exists because IPv4 and IPv6 both guarantee that 1,280-byte packets will not be fragmented (1,280 bytes minus 40 bytes of IPv6 header minus 8 bytes of UDP header equals 1,232 bytes of payload, rounded down to 1,200 for safety).

Any QUIC implementation that wants to send larger packets must perform Path MTU Discovery (PMTUD) first. PMTUD is unreliable on the public internet because many firewalls block the ICMP messages that PMTUD relies on. So most QUIC stacks send 1,200-byte packets for the entire handshake and only grow packet size after the connection is established and PMTUD has had a chance to converge.

This means hybrid PQC handshakes are more likely to need multiple packets than they would be on a network where PMTUD reliably reports a higher MTU.

Anti-Amplification Limits

Another QUIC-specific complication is the anti-amplification limit. RFC 9000 mandates that a server sending data in response to a client's first datagram must not send more than 3x the bytes the client sent.

This matters for PQC because the server's response includes ServerHello, EncryptedExtensions, Certificate, CertificateVerify, and Finished. A typical ECDSA-signed certificate chain is 2-3 KB. A future ML-DSA-signed certificate chain is 12-18 KB. The server's response can easily exceed 3x the client's 1,200-byte first packet, especially with PQC certificates.

The fix is that the server must wait for the client to send more data (and thereby raise the anti-amplification budget) before completing its half of the handshake. This adds round-trips. The IETF is exploring solutions including:

Client-side address validation tokens (so the server can skip anti-amplification).
Compressed certificate transmission (RFC 8879).
Out-of-band certificate distribution.

For pure-key-exchange PQC (X25519MLKEM768 without PQC certificates), the anti-amplification constraint is mostly handled in current implementations. The harder problem comes when full PQC certificate chains arrive.

QUIC's Packet Number Encryption

A subtle but important QUIC mechanism is header protection: the packet number in each QUIC packet is masked using a header-protection key: AES applied to a sample of the packet ciphertext (or raw ChaCha20), per RFC 9001. This prevents passive observers from reordering packets or doing traffic analysis.

The packet number encryption keys come from the same key schedule as the TLS session keys. So when TLS migrates to a hybrid PQC key exchange, the packet number encryption keys are derived from a hybrid shared secret too. No additional change to the QUIC layer is needed; the change happens entirely inside TLS.

This is one of the cleaner aspects of QUIC PQC migration: the key exchange is the only place where PQC actually shows up. Everything else (transport parameters, frames, connection IDs, version negotiation) is unchanged.

Connection Migration And PQC

QUIC's most distinctive feature is connection migration: a connection can survive an IP address change. If a mobile device switches from Wi-Fi to cellular, the QUIC connection's identifier stays the same and traffic resumes on the new path after path validation.

PQC does not affect connection migration directly. Path validation uses a challenge-response with a random token, secured by the existing session keys. As long as the initial handshake established the session keys (which it does, with hybrid PQC), migration works exactly as before.

HTTP/3 And PQC

HTTP/3, defined in RFC 9114, is HTTP semantics over QUIC. The PQC story for HTTP/3 is identical to QUIC's: the underlying QUIC connection negotiates a hybrid PQC handshake, and HTTP/3 traffic flows over that connection unchanged.

For application developers, PQC HTTP/3 is invisible. Browsers and servers handle it. The only operational signal is that handshakes are slightly larger and slightly slower.

Real-World Deployment Numbers

Cloudflare publishes regular telemetry on PQC adoption. As of mid-2025, more than 60% of compatible QUIC clients (Chrome 124+, Firefox 132+, Edge 126+) connecting to Cloudflare-fronted sites use the X25519MLKEM768 hybrid group. Google's QUIC stack inside Chrome was an early adopter, with experimental Kyber768 support as far back as 2022 and final ML-KEM-768 support since 2024.

For HTTP/3 specifically, the percentage is similar because HTTP/3 just inherits QUIC's negotiation. The PQC adoption curve is essentially the same as TLS 1.3's.

What Server Operators Need To Do

If you operate an HTTP/3 server today and want PQC support:

Update your QUIC library. msquic 2.4+, quiche 0.22+, lsquic 4.0+, ngtcp2 1.6+ all ship X25519MLKEM768 support.
Update your TLS library. Your QUIC stack uses a TLS library underneath (BoringSSL, OpenSSL 3.5+, rustls). The TLS library is what actually implements the hybrid group.
Configure groups. Add X25519MLKEM768 to your supported groups list, ahead of X25519 and secp256r1.
Test with a hybrid-capable client. Chrome 124+ in default config will negotiate hybrid. Verify with Wireshark or browser developer tools.
Monitor. Watch your handshake latency metrics. The hybrid handshake adds 4-5 ms median in most networks.

For a deeper dive on the TLS-side configuration, see our TLS 1.3 hybrid handshake article.

QUIC Version Negotiation And PQC

QUIC supports version negotiation via the version field in the long header. Currently QUIC v1 (RFC 9000) and QUIC v2 (RFC 9369) are the standardized versions. PQC does not require a new QUIC version, the cryptographic upgrade happens entirely in the TLS layer that QUIC carries.

This is operationally helpful: an existing QUIC v1 deployment can add PQC support purely by upgrading its TLS library and configuration. No QUIC-level migration is needed.

QUIC On Datacenter Networks

A growing use case for QUIC is intra-datacenter traffic, where Google and other large operators are exploring QUIC as a replacement for TCP for service-to-service communication. In this context, all clients and servers are under one organization's control, MTU is well-understood, and middleboxes are absent.

For datacenter QUIC, PQC migration is dramatically easier than on the public internet. The operator can mandate hybrid PQC, refuse classical fallback, and handle MTU carefully. Some Google internal services are already running pure-PQC TLS 1.3 over QUIC for service-to-service traffic.

What QNSQY Does

QNSQY's billing API is fronted by Cloudflare, which means HTTP/3 with hybrid PQC is automatic for compatible clients. We do not run our own QUIC stack; we let Cloudflare handle it. This is the typical SaaS pattern for PQC migration: rely on your CDN or edge provider for transport-layer PQC, focus your own engineering on application-layer PQC (file encryption, token signing, etc.).

For QNSQY-encrypted files specifically, the file format does not depend on QUIC at all. A QNSQY-encrypted file is a static envelope that can travel over any transport. PQC for the file content is provided by the hybrid encryption inside the QSPG v2 format.

Frequently Asked Questions

Q: Is HTTP/3 quantum-safe today? HTTP/3 over QUIC over TLS 1.3 with X25519MLKEM768 is quantum-safe for key exchange, yes. Server certificates are still classical (RSA or ECDSA), which leaves a window for forward identity forgery if quantum capability arrives, but the session itself is protected.

Q: Does PQC slow down HTTP/3 noticeably? 4-5 ms added handshake latency on most networks, plus a small bandwidth increase. For long-lived connections (most HTTP/3 traffic), this is invisible. For short connections that handshake repeatedly, it adds up but is rarely the bottleneck.

Q: Will my HTTP/3 server need a configuration change? If you use a CDN, probably not, the CDN handles it. If you run your own HTTP/3 server, yes, you need to enable the hybrid group in your TLS configuration.

Q: What about HTTP/3 over WebTransport? WebTransport is a separate API on top of HTTP/3 (or sometimes HTTP/2). It inherits the underlying QUIC connection's PQC properties. No additional changes needed at the WebTransport layer.

Q: Are there middleboxes that break PQC HTTP/3? Some old DDoS appliances and corporate firewalls have known issues with multi-packet QUIC Initial packets. The number is decreasing as vendors update. If you see handshake failures specifically with PQC clients but not classical clients, this is a likely cause.

Sources

RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport. https://datatracker.ietf.org/doc/html/rfc9000
RFC 9114, HTTP/3. https://datatracker.ietf.org/doc/html/rfc9114
NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism. https://csrc.nist.gov/pubs/fips/203/final
Cloudflare Research, The state of the post-quantum Internet. https://blog.cloudflare.com/pq-2024/
RFC 8446, TLS 1.3. https://datatracker.ietf.org/doc/html/rfc8446
RFC 8879, TLS Certificate Compression. https://datatracker.ietf.org/doc/html/rfc8879

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY