The run did not exercise this test: the client sent no early data, so nothing was rejected. A session was issued for it to resume from, so the opportunity existed -- but whether this client resumed the session at all is not observable from this end, and a client that failed to store the ticket looks exactly like one that stored it and chose not to offer early data.
The suite could not establish what this client does here. That is a shortcoming of the run rather than anything about the client, and every one of these is on our list to remove.
What was measured
- Client
- quic-go — quic-go, quic-go v0.61.0 (h1:9So2anK4Tp22)
- 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-09-19
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 quic-go at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-zero-rtt-reject"]'