The run did not exercise this test: the client sent no early data, so it was never answered 425. 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
- chromium — Chromium QUICHE, build 1223
- Test
- 425 (Too Early) in answer to a request sent as early data —
q-zero-rtt-replay - Clause
- RFC 8470 §5.2 (SHOULD)
- Class
- discretionary — The RFC permits either behaviour; the report says which was chosen.
- Required behaviour
- Handle being told the request arrived too early. §5.2 says a user agent "SHOULD retry automatically, but any retries MUST NOT be sent in early data" — so retrying on the 1-RTT keys and handing the 425 back to the caller are both conformant, and the report says which happened. Falling over is not one of the options. This is the only port that *accepts* early data instead of refusing it, which is what makes the 425 exchange possible at all. What it does not check is §4's rule that unsafe methods must never be sent in early data: reading the method would mean QPACK-decoding the request, which this suite deliberately never does. Reaching it needs a session ticket from an earlier connection to this same port, so a client that connects once has none.
- 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 chromium at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-zero-rtt-replay"]'