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

Inconclusive

The run did not exercise this test: the client sent no early data, so nothing was rejected. 0-RTT needs a session ticket from an earlier connection to this same port, and a client that connects once has none.

The run did not establish what this client does here — either it was never put in the situation, or its answer admits more than one reading. Not a failure, and never counted as one.

What was measured

Client

ngtcp2 — ngtcp2 + nghttp3 (direct), 3c23148

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-18

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 ngtcp2 at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-zero-rtt-reject"]'