q-key-update-repeated
· RFC 9001 §6.1, §6.5 · interoperability · layer quic · udp/4509 · MUST
Passing this means: Correctly decoded something valid but demanding.
Anomaly type: transport
How each client answered
| Client | Version | Verdict | What happened |
|---|---|---|---|
| curl | ngtcp2/1.11.0 | Pass | Decoded it and completed the request. |
| quinn | noq fork | Pass | Decoded it and completed the request. |
| aioquic | 1.3.0 | Pass | Decoded it and completed the request. |
| chromium | build 1223 | Pass | Decoded it and completed the request. |
| quic-go | quic-go v0.61.0 | Pass | Decoded it and completed the request. |
| quiche | 0.30.0 | Pass | Decoded it and completed the request. |
| neqo | 0.31.1 | Pass | Decoded it and completed the request. |
What the clause requires
Follow both updates and carry on. §6.1 lets an endpoint update again once the previous phase has been acknowledged, so a long-lived connection changes keys repeatedly and a client has to track the phase rather than assume one change. Distinct from the single update on the neighbouring port. An implementation that hardcodes the first transition — treating key phase as a one-way flag rather than a bit that alternates — passes that test and fails here, which is precisely the bug worth finding.
Judged against RFC 9001.
Run this one yourself
Every test is reachable from your own client. Nothing here needs an account.
curl -s https://conformance.pqcrypta.com/catalog.json \
| jq '.tests[] | select(.id == "q-key-update-repeated")'What this suite is · The full grid · All clients · All tests · Findings