up:: In the Protocols MOC

QUIC

QUIC is a secure, general-purpose transport protocol that runs over UDP and carries most HTTP/3 traffic, and it establishes its session keys by embedding the TLS 1.3 handshake directly inside its own connection setup. Where classic web traffic runs TLS on top of TCP, QUIC folds connection establishment, TLS 1.3 key exchange, and encrypted delivery into one fast handshake over UDP. That decision settles its quantum story: because QUIC gets its keys from TLS 1.3, its post-quantum migration rides on the same TLS 1.3 hybrid key exchange that secures TLS over TCP, the X25519MLKEM768 group. The wrinkle that belongs to QUIC alone is size. A larger post-quantum handshake collides with QUIC’s anti-amplification limit and its fixed minimum packet size, and that collision is where a QUIC rollout gets interesting.

The short version:

• QUIC is the UDP-based transport underneath HTTP/3, defined in RFC 9000, and it merges connection setup, TLS 1.3 key establishment, and encrypted transport into a single 1-RTT handshake (often 0-RTT on resumption).
• It gets its keys from TLS 1.3 embedded inside the connection: TLS handshake messages ride in QUIC CRYPTO frames rather than the TLS record layer, and QUIC forbids any TLS below 1.3.
• Because the key exchange is TLS 1.3’s, QUIC goes post-quantum the same way TLS does, through the hybrid group X25519MLKEM768 (classical X25519 plus ML-KEM-768), so the migration reuses the TLS work instead of inventing a separate one.
• The QUIC-specific trap is two hard limits pulling against a bigger handshake: every client Initial packet is padded to at least 1200 bytes, and a server may not send more than three times the bytes it received before it validates the client’s address, so a large post-quantum flight can hit that ceiling and stall or cost an extra round trip.
• Key exchange is the harvest-now-decrypt-later half and migrates first; certificate signatures are the slower Non-HNDL track, and it’s the post-quantum certificate chains that strain the amplification budget the most.

Picture a guard at a night window who, until he has checked who you are, will pass back only three pages for every one page you slide through the slot. Normally his answer is short, so the three-for-one allowance covers it easily. Post-quantum makes his answer much longer, because the new keys and signatures are bigger, so he runs out of his three-for-one budget partway through and has to pause until you push more pages through the slot. That pause is the extra round trip. The lock on the window is fine, and the guard is happy to use the new keys. The whole QUIC-specific fight is that the answer got too big for the budget.

What is QUIC?

QUIC is a UDP-based, multiplexed, secure transport protocol standardized as RFC 9000, and it’s the transport that HTTP/3 runs on. Where HTTP/2 and earlier ran over TLS over TCP, HTTP/3 is defined as a mapping of HTTP semantics onto QUIC, so in practice QUIC is the layer doing the connection, encryption, and delivery for a modern HTTP/3 site.

QUIC exists because bolting TLS onto TCP left performance and flexibility on the table, and it fixes several things at once:

1. It merges the transport and the crypto handshake. A QUIC connection sets up the transport and the TLS 1.3 keys together, reaching a usable encrypted connection in a single round trip, and zero round trips when resuming a prior session.
2. It multiplexes streams without head-of-line blocking. QUIC carries application data in independent streams, “ordered sequences of bytes,” so a lost packet on one stream doesn’t stall the others the way it does under a single TCP connection.
3. It survives a change of network path. QUIC identifies a connection by a connection ID rather than by the IP-address-and-port tuple, so a session can migrate from Wi-Fi to cellular without tearing down and rebuilding.
4. It’s encrypted by default and hard to ossify. Almost the entire QUIC header and payload are protected, which both secures the traffic and hides the internals from the middleboxes that calcified TCP.

The thing to hold onto is that QUIC is a transport that has TLS 1.3 built into it, rather than a transport you later wrap in TLS. That single fact is what determines how it goes post-quantum.

Source: J. Iyengar, M. Thomson, “QUIC, A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021, rfc-editor.org.

Source: M. Bishop, “HTTP/3,” RFC 9114, June 2022, rfc-editor.org.

Where does cryptography live in QUIC?

Cryptography in QUIC lives in the TLS 1.3 handshake that QUIC carries inside its own packets, so the quantum-vulnerable math sits in exactly the same place it sits in TLS. RFC 9001, the specification for using TLS to secure QUIC, describes the arrangement as a clean division of labor: “QUIC uses the TLS handshake; TLS uses the reliability, ordered delivery, and record layer provided by QUIC.”

The mechanics of that split matter for understanding the exposure:

1. The handshake rides in CRYPTO frames. QUIC takes the TLS handshake messages, the ClientHello, the server’s key share, its certificate, and its signature, and carries them in QUIC CRYPTO frames. As RFC 9001 puts it, “TLS record protection is not used by QUIC,” because QUIC provides its own packet protection instead.
2. The keys come from TLS. QUIC derives its packet-protection keys the same way TLS derives record-protection keys, from the traffic secrets that “are derived by TLS.” So the shared secret that protects a QUIC connection is the output of the TLS 1.3 key exchange, computed inside the embedded handshake.
3. Only TLS 1.3 or newer is allowed. RFC 9001 is strict here: “Clients MUST NOT offer TLS versions older than 1.3,” and an endpoint “MUST terminate the connection” if anything older is negotiated. There’s no legacy-TLS foot-gun in QUIC the way TLS 1.2 still permits static RSA.

Because the crypto is TLS 1.3’s crypto, the same three-role breakdown applies. The key exchange (classical ECDHE, usually X25519) is the piece broken by Shor’s algorithm and harvestable today. The certificate signature (RSA or ECDSA) is also breakable by Shor’s, but only useful to forge live, so it’s a slower-clock problem. The symmetric packet protection (AES-GCM or ChaCha20-Poly1305) is durable and only needs a larger key against Grover’s algorithm.

QUIC cryptographic role	The algorithm today	Quantum threat	Exposure class	Urgency
Key exchange (in the embedded TLS 1.3 handshake)	ECDHE / X25519	Broken by Shor’s	HNDL, harvestable today	Highest, migrate first
Certificate signature	RSA / ECDSA	Broken by Shor’s	Non-HNDL, needs a live CRQC	Slower track
Packet protection	AES-GCM / ChaCha20-Poly1305	Weakened by Grover’s	Retain and strengthen	Use a 256-bit key, no swap

Source: M. Thomson, S. Turner, “Using TLS to Secure QUIC,” RFC 9001, §3, §4.1, §4.2, §5.1, May 2021, rfc-editor.org.

How does QUIC go post-quantum?

QUIC goes quantum-safe by making its embedded TLS 1.3 handshake use hybrid key exchange, which means the whole move is inherited from TLS rather than invented for QUIC. The handshake negotiates the named group X25519MLKEM768, pairing classical X25519 with ML-KEM-768, NIST’s standardized lattice-based key-encapsulation mechanism, and folds both shared secrets into the key schedule so the session holds if either component survives. This is the hybrid pattern, and it closes the harvest-now-decrypt-later window on live QUIC traffic.

The sequencing follows the two clocks:

1. Key exchange first. Because the shared secret is harvestable, the urgent move is the hybrid group in the handshake. This is already shipping over HTTP/3: Firefox added the mlkem768x25519 post-quantum key exchange and reached HTTP/3 with it in Firefox 135 (February 2025), and Chromium browsers ship X25519MLKEM768 by default, so a modern browser talking to a modern QUIC server negotiates post-quantum keys today.
2. Certificate signatures later. The authentication side migrates toward ML-DSA as the general-purpose signature, with SLH-DSA where a conservative hash-based scheme is preferred, and composite certificates carry both a classical and a post-quantum signature during the overlap. This side moves slower because it touches the entire certificate ecosystem, and, as the next section shows, it’s the part that strains QUIC’s amplification budget hardest.
3. Packet protection stays. The symmetric encryption of the actual QUIC payload needs no post-quantum swap. A 256-bit key (AES-256 or ChaCha20-Poly1305) keeps a comfortable margin against Grover’s algorithm.

The practical upshot is that there’s no separate “post-quantum QUIC” cryptography to design. QUIC’s confidentiality plane goes quantum-safe the moment its embedded TLS 1.3 stack negotiates the hybrid group, which is why the QUIC conversation is really a deployment conversation.

Source: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov.

Source: Mozilla, “Firefox 135 release notes” (mlkem768x25519 for HTTP/3), February 2025, mozilla.org.

Why does a post-quantum handshake strain QUIC’s anti-amplification limit?

This is the wrinkle that belongs to QUIC and not to TLS-over-TCP, and it comes from two hard rules in RFC 9000 that were written to stop QUIC servers from being abused as traffic amplifiers. A post-quantum handshake is bigger, and a bigger handshake pushes against both rules at once.

The two rules:

1. The minimum Initial-packet size. RFC 9000 §14.1 requires that a client “expand the payload of all UDP datagrams that carry Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes.” So a client’s first flight is always padded up to at least 1200 bytes, whether or not the handshake needs the room.
2. The anti-amplification limit. RFC 9000 §8.1 states that “prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes received from the client address.” Until the server has confirmed the client is really at the address it claims, the server’s reply is capped at three times what the client sent.

Here’s how post-quantum collides with them. A classical X25519 key share is 32 bytes, so a classical ClientHello slots easily inside one 1200-byte Initial packet, and the server’s three-for-one budget of roughly 3600 bytes comfortably covers its reply. A hybrid X25519MLKEM768 share is far larger: the ML-KEM-768 encapsulation key alone is 1184 bytes, pushing the client’s key share to about 1216 bytes. RFC 9001 §4.3 anticipates exactly this, warning that “large session tickets, multiple or large key shares, and long lists of supported ciphers” can push the ClientHello past a single packet, and that “if the ClientHello spans multiple Initial packets, such servers would need to buffer the first received fragments, which could consume excessive resources if the client’s address has not yet been validated.”

Two consequences follow, and both cost a round trip:

1. The server can hit the 3x ceiling and stall. The reply the server owes grows with post-quantum material, most sharply once post-quantum certificate chains and multi-kilobyte ML-DSA signatures enter the flight. When that reply exceeds three times what the client has sent so far, the server has to stop and wait for the client to send more packets (acknowledgements or additional data) before it’s allowed to continue, which turns a clean 1-RTT setup into a slower one and can look like a stall on the wire.
2. A multi-packet ClientHello can trigger a Retry. To avoid buffering handshake fragments from an unvalidated address, RFC 9001 §4.3 notes that “servers MAY use the Retry feature to only buffer partial ClientHello messages from clients with a validated address.” A Retry validates the address first, then asks the client to start again, which also adds a round trip.

Handshake	Client key share	Client Initial flight	Server 3x budget before validation	Result
Classical (X25519)	32 B	One padded 1200 B packet	~3600 B	Fits comfortably, clean 1-RTT
Post-quantum key exchange (X25519MLKEM768)	~1216 B (ML-KEM-768 encap key 1184 B + X25519 32 B)	May span two Initial packets	3x of what the client actually sent	Usually fits once the client pads across packets; watch for Retry on a multi-packet ClientHello
Post-quantum key exchange + PQC certificate chain	~1216 B in, large ML-DSA signatures out	Two or more Initial packets	3x of received bytes	The server flight can exceed the budget, forcing it to wait for more client packets, adding a round trip

The honest read is that QUIC’s minimum-datagram rule actually helps the client, because padding the Initial flight raises the server’s three-for-one budget. The squeeze is on the server’s side of a fully post-quantum handshake, and the design lever is the same one TLS uses on TCP: get the harvestable key exchange migrated first, where the amplification cost is manageable, and stage the heavier certificate migration deliberately.

Source: J. Iyengar, M. Thomson, “QUIC, A UDP-Based Multiplexed and Secure Transport,” RFC 9000, §8.1 (anti-amplification) and §14.1 (Initial datagram size), May 2021, rfc-editor.org.

Source: M. Thomson, S. Turner, “Using TLS to Secure QUIC,” RFC 9001, §4.3 (ClientHello Size), May 2021, rfc-editor.org.

Source: K. Kwiatkowski, P. Kampanakis, B. Westerbaan, D. Stebila, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,” draft-ietf-tls-ecdhe-mlkem (ML-KEM-768 encapsulation key 1184 B), datatracker.ietf.org.

What does migrating QUIC actually look like?

Migrating QUIC is a rollout tracked endpoint by endpoint, governed by the same rule that governs all applied PQC: a protocol is only as quantum-safe as its weakest deployed endpoint. A QUIC session goes hybrid only when both ends negotiate the hybrid group, so one un-migrated endpoint keeps the classical fallback in play. A few features are specific to QUIC:

1. QUIC termination is usually a vendor surface. HTTP/3 is very often terminated at a CDN edge, a cloud load balancer, or a reverse proxy rather than on the origin application, so for a large share of traffic the hybrid group arrives when the provider ships it. Migration timing depends on vendor roadmaps as much as on internal work, exactly as it does for TLS.
2. The application rarely changes. Because the key exchange lives in the QUIC library’s embedded TLS stack, gaining post-quantum key exchange is a dependency or firmware upgrade at the termination layer, not an application rewrite.
3. The UDP path is its own variable. QUIC runs over UDP on port 443, and some networks rate-limit, throttle, or block UDP, which already forces clients to fall back from HTTP/3 to HTTP/2 over TLS-over-TCP. A post-quantum plan has to cover both paths, because a session that falls back to TCP still needs its TLS key exchange migrated, and the larger UDP datagrams of a hybrid handshake give middleboxes one more reason to interfere.
4. You confirm it on the wire. An HTTP/3 connection looks identical whether it negotiated classical or hybrid key exchange, so the proof is the negotiated group in a packet capture of the handshake, plus the endpoint’s permitted configuration, rolled into a cryptographic bill of materials so the posture is defensible to a board and an auditor.

Underneath all of it is a crypto-agility question. A QUIC stack that can negotiate a new key-exchange group and retire an old one migrates cleanly; a deployment pinned to one algorithm or one QUIC library version has to be upgraded before it can move at all.

How urgent is the QUIC migration?

QUIC key exchange is as time-sensitive as TLS key exchange, and Mosca’s theorem frames why: if the time your data must stay confidential plus the time your migration takes exceeds the time until a capable quantum computer exists, the data captured now is already exposed. QUIC carries a growing share of long-lived, sensitive web and API traffic, and its key exchange is harvestable today, so anything that must stay secret for years argues for enabling the hybrid group early. The certificate side is genuinely less urgent on the clock because it’s a live-forgery problem with nothing to harvest, which is fortunate, since it’s also the side that strains QUIC’s amplification budget the most and benefits from a deliberate, staged rollout.

Common misconceptions

• “QUIC uses its own cryptography, so post-quantum QUIC is a separate project.” QUIC embeds the TLS 1.3 handshake for key establishment, so its post-quantum move is the TLS hybrid group X25519MLKEM768, and the work is largely shared with the TLS migration rather than duplicated.
• “Quantum computers break QUIC’s encryption.” The transport and its symmetric packet protection hold. The vulnerable pieces are the key exchange and the certificate signature inside the embedded TLS handshake, and the fix swaps those while keeping QUIC.
• “The 1-RTT handshake means post-quantum is free here.” The larger post-quantum flight can hit QUIC’s anti-amplification limit or force a Retry, and either one adds a round trip, so the cost shows up as latency and handshake failures rather than as CPU.
• “We’re on HTTP/3, so we’re quantum-safe.” HTTP/3 tells you QUIC is present, not which key-exchange group the handshake negotiated. Quantum safety is the separate step of negotiating the hybrid group across every endpoint.
• “0-RTT resumption changes the exposure.” Session resumption reuses established secrets and doesn’t alter which key-exchange algorithm protects the connection, so a 0-RTT QUIC session inherits whatever exposure its original handshake had.
• “Enabling the hybrid group is a config flag and we’re done.” A session goes hybrid only when both endpoints and the whole UDP path support it, so the real work is coverage across every CDN edge, load balancer, proxy, and firewall that touches the traffic.

Questions people ask

Is my HTTP/3 site quantum-safe? Only if its QUIC handshake actually negotiates a hybrid key-exchange group like X25519MLKEM768. HTTP/3 running over QUIC gives you TLS 1.3 keys, and quantum safety is the added step of enabling the hybrid group at whatever terminates your QUIC, which is frequently a CDN or load balancer you configure rather than your application.

What actually changes in QUIC for post-quantum? The key-exchange step inside the embedded TLS 1.3 handshake changes first, from classical ECDHE to the hybrid group that runs X25519 and ML-KEM-768 together. Certificate signatures change later, toward ML-DSA or SLH-DSA. The symmetric packet protection stays put with a 256-bit key.

Why does QUIC have an amplification problem that TLS over TCP doesn’t? QUIC’s anti-amplification rule is explicit and numeric: RFC 9000 §8.1 caps a server at three times the bytes it received before it validates the client’s address, and §14.1 fixes a 1200-byte minimum Initial packet. A larger post-quantum handshake pushes against both, so the interop cost surfaces as amplification stalls and possible Retries rather than only as the oversized-ClientHello middlebox issue TLS-over-TCP sees.

Do I have to rewrite my application? Usually not. QUIC and its embedded TLS live in a library or an appliance, so post-quantum key exchange comes from upgrading that QUIC stack and enabling the hybrid group, not from application code. The termination layer does the work.

Is post-quantum QUIC deployable today? Yes, for key exchange. Firefox reached HTTP/3 with mlkem768x25519 in version 135 (February 2025), Chromium browsers ship X25519MLKEM768 by default, and server-side QUIC libraries built on post-quantum-capable TLS stacks negotiate it. Post-quantum certificate signatures trail behind on their own timeline.

What breaks in production when I turn on hybrid QUIC? Two QUIC-specific failure modes join the usual ones: the server can hit the anti-amplification limit on a large post-quantum flight and stall for a round trip, and a multi-packet ClientHello can trigger a Retry. On top of that, the UDP path itself may drop or throttle the larger datagrams, so testing the full network path is what catches it.

Which migrates first, key exchange or signatures? Key exchange, clearly. It’s harvestable today, so a recorded QUIC session is a future liability, while signatures are Non-HNDL and need a live quantum computer to forge. The ordering is also kind to QUIC’s amplification budget, since the heavier certificate migration is the part that strains it most and can be staged deliberately.

Does falling back to HTTP/2 make the post-quantum question go away? No, it moves it. When a network blocks UDP and the client falls back to HTTP/2 over TLS-over-TCP, that path still runs a classical key exchange that needs the same hybrid migration. Covering QUIC without covering the TCP fallback leaves the exposure open on whichever path a given client ends up using.

---

Everything here is the map, given freely. When your team needs its own HTTP/3 and QUIC termination points found, its harvestable key exchange prioritized, and a hybrid rollout sequenced across every edge, proxy, and vendor surface without tripping the amplification limit, defensible to your board and your auditor, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.