Decoded it and completed the request.
The client did what the clause requires.
What was measured
- Client
- neqo — neqo (Firefox), 0.31.1 (cac2b74)
- Test
- A second key update after the first is acknowledged —
q-key-update-repeated - Clause
- RFC 9001 §6.1, §6.5 (MUST)
- Class
- interoperability — Correctly decoded something valid but demanding.
- Required behaviour
- 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.
- 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 neqo at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-key-update-repeated"]'