The remaining 🟦 cosmetic items from the 2026-05-09 audit. Pre-fix the
connection's `closeErrorCode` was effectively unused — TLS handshake
failures bubbled up as generic `QuicCodecException` and observers had
to grep the reason string for the spec category. Now closeErrorCode
carries the RFC 9000 §20.1 transport code or the RFC 9001 §4.8
TLS-alert-mapped CRYPTO_ERROR.
Implementation:
* `TlsAlertException(alertCode, message)` carrier raised by the
TLS layer for the well-defined cases:
- HelloRetryRequest received (handshake_failure = 40)
- TLS 1.3 not negotiated (protocol_version = 70)
- Unsupported cipher (illegal_parameter = 47)
- ALPN mismatch (no_application_protocol = 120)
- Cert chain validation failure (bad_certificate = 42)
- CertificateVerify signature failure (decrypt_error = 51)
- Server Finished MAC mismatch (decrypt_error = 51)
- TLS KeyUpdate over QUIC (unexpected_message = 10) — RFC 9001
§6 mandates this specific code; fixes the misleading prior
message that said "rotation not implemented" (we DO implement
QUIC's own KEY_PHASE-bit rotation).
The QUIC parser maps `0x100 + alertCode` per RFC 9001 §4.8 and
stamps `closeErrorCode`.
* `QuicTransportError` constants object covering the RFC 9000 §20.1
table (NO_ERROR through NO_VIABLE_PATH including the previously-
flagged CRYPTO_BUFFER_EXCEEDED 0x0d, KEY_UPDATE_ERROR 0x0e,
AEAD_LIMIT_REACHED 0x0f).
* `markClosedExternally(reason, errorCode = NO_ERROR)` overload —
backward compatible; lets call sites pin the spec code on
`closeErrorCode` for qlog observability without changing the
wire-emit semantics (still no CONNECTION_CLOSE frame, same as
before — that's a separate, larger refactor).
* RFC 9000 §22 CRYPTO_BUFFER_EXCEEDED enforcement — pre-insert
per-level cap of 64 KiB on inbound CRYPTO data. Generous enough
for an RSA-4096 cert chain with intermediates; bounds the
worst-case heap a misbehaving peer can pin to 192 KiB across
all 3 encryption levels. Fires before the receive buffer
actually allocates.
* INVALID_TOKEN — N/A for client role (only servers validate Retry
tokens). KEY_UPDATE_ERROR — exposed as a constant; no current
failure path maps to it (PN regression on a key-update packet
is spec-allowed to handle silently per RFC 9001 §6.1, which we
do).
Tests: `ErrorCodeMappingTest` (6 cases) covers TlsAlertException
construction + offset, alert code bounds, markClosedExternally
preservation, CRYPTO_BUFFER_EXCEEDED close, sanity-check that small
CRYPTO frames don't trip the cap, and §20.1 numeric values.
`HelloRetryRequestTest` updated to expect TlsAlertException(40)
instead of generic QuicCodecException.
Plan updated to mark the §4.8 + §22 (CRYPTO_BUFFER_EXCEEDED) items
resolved; KEY_UPDATE_ERROR documented as TLS-side covered + QUIC-side
spec-allowed-silent; INVALID_TOKEN documented as N/A for client.
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
Claude
6cc1bf6433