PQ Crypta Logo

quiche — 0-RTT rejected after the client sends early data

The client does not do this, and said so itself — by what it advertised, or by refusing outright. A definite answer about the client, not a failure and not a gap.

PQ CRYPTA PLATFORM

🏠 Main

📰 News

👤 Account

⟨ QUANTUM ERROR PORTAL ⟩

Navigate the Error Dimensions

Jump to an anomaly59

Every one of these is a page: what the server emits, the clause it is judged against, and how each client answered. The full list carries the verdict tallies too.

Unsupported

does not deliver early data to an endpoint that negotiates versions, so nothing was rejected. It offered a GREASE QUIC version first, which this endpoint answered with Version Negotiation (RFC 8999 §6), and it did not re-offer early data on the v1 retry -- so the 0-RTT it intended never reached the wire. Both sides are conformant; the early data is lost between them.

The client does not do this, and said so itself — by what it advertised, or by refusing outright. A definite answer about the client, not a failure and not a gap.

Why the run landed here

quiche's early data is lost to its own version GREASE before the resumption is ever tried.

quiche opens with a GREASEd QUIC version (0xbabababa) carrying its first flight. This endpoint answers that correctly with Version Negotiation, and the early data in that flight goes with it; the retry that follows on a real version carries none. So the run cannot reject early data that was never offered. This is conformant on both sides — the client is allowed to GREASE the version and the server is required to negotiate it — and it is the reason two of quiche's cells reach no verdict rather than any defect in its 0-RTT.

Established separately from the run and recorded beside it, not in it: the verdict above is still only what the server could see. Measured by packet decode of the client's first flight, including coalesced packets; pqcrypta-proxy/src/conformance/listener.rs no_early_data(), 2026-09-19.

What was measured

Client
quiche — Cloudflare quiche, 0.30.0 (1c8e976)
Test
0-RTT rejected after the client sends early data — q-zero-rtt-reject
Clause
RFC 9001 §4.6.2 (MUST)
Class
resilience — Recovered rather than giving up.
Required behaviour
Reset the state of every stream, including application state bound to them. Section 4.6.2 requires the reset because a rejected 0-RTT means every assumed connection characteristic may have been wrong. It does not require retransmission, which is the application concern, not QUIC's. This port issues tickets that advertise early data and then declines every offer, so a resuming client sends 0-RTT and always has it refused. The handshake itself completes normally.
Measured
2026-10-27

Reproduce it

The suite is the judge, so the reproduction is to point the same client at the same test and let the server report what it saw.

SESSION=$(curl -sX POST https://conformance.pqcrypta.com/session | jq -r .id)
# then drive quiche at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-zero-rtt-reject"]'