Per moq-lite Lite-03 (kixelated/moq `rs/moq-lite/src/lite/announce.rs`),
a publisher MUST only emit `Announce(Active)` for broadcasts whose path
starts with the requested AnnouncePlease prefix. Pre-fix, when
`MoqLitePath.stripPrefix(please.prefix, ourSuffix)` returned `null`, we
fell through to `?: announcePublisher.suffix` and emitted Active under
our full suffix anyway, falsely advertising the broadcast under a
prefix the subscriber didn't request.
Production never bit because the relay always opens its announce bidi
to us with `prefix=""` (which always matches), but a future peer-to-
peer or namespace-scoped subscriber would have observed a ghost
broadcast under whatever prefix they asked about.
The fix: if `stripPrefix` returns `null`, FIN the bidi cleanly without
writing any Announce body. The subscriber sees an empty announce
stream and moves on.
Regression test:
`MoqLiteSessionTest.publisher_skips_announce_when_announce_please_prefix_does_not_match`.
Audit doc: nestsClient/plans/2026-05-09-moq-lite-rfc-compliance.md (M4).
https://claude.ai/code/session_012TGfo99Ugz7fcCPv85a8Tq
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
Two related improvements for the audio-rooms moq-lite path on mobile.
** RFC 9114 §6.2.1 + RFC 9204 §4.2 critical-stream closure **
When the peer closes a critical unidirectional stream — control (0x00),
QPACK encoder (0x02), or QPACK decoder (0x03) — the spec MANDATES we
treat it as a connection error of type H3_CLOSED_CRITICAL_STREAM.
Pre-fix the demux only set `peerH3ProtocolError` flag on protocol
violations, with no autonomous close on clean FIN; the application
was expected to poll. For audio rooms running on lossy mobile paths,
relay-side control-stream drops left users staring at silent audio.
* `Http3ErrorCode` constants for the §8.1 error-code table.
* `WtPeerStreamDemux.drainControlStream` calls `connection.close(...)`
on either clean FIN (H3_CLOSED_CRITICAL_STREAM) or QuicCodecException
raised by the frame reader (specific code via
[http3ErrorCodeForMessage] map: H3_MISSING_SETTINGS,
H3_FRAME_UNEXPECTED, H3_SETTINGS_ERROR, H3_ID_ERROR, etc.).
* New `drainCriticalStream` helper fires the same close on QPACK
encoder / decoder FIN (RFC 9204 §4.2).
* Closure intent latched on `criticalStreamClosureCode` /
`criticalStreamClosureReason` so tests can verify the path runs
without wiring a real driver.
** RFC 9000 §10.3 stateless-reset tokens for migrated CIDs **
The 2026-05-09 stateless-reset detection covered tokens in the
unused-CID pool but lost them the moment a CID was rotated to active
via `tryStartValidation` (WiFi handoff) or `forceRotateToHigherSequence`
(peer-forced retire). On the new path the migrated token wouldn't
match — relay crash mid-handoff would silently hang until idle timeout.
* `PathValidator.knownStatelessResetTokens` — append-only lifetime
store, populated in `recordPeerNewConnectionId`. Survives rotation.
* `QuicConnection.isStatelessReset` walks the lifetime store instead
of the unused pool.
* §10.3.1 explicitly permits keeping tokens after retirement; cost
is ~16 bytes per peer-issued CID.
Tests:
* `CriticalStreamClosureTest` (5 cases) — control FIN, QPACK FIN,
MISSING_SETTINGS, FRAME_UNEXPECTED, idempotency.
* `StatelessResetDetectionTest` extended with 2 cases —
`token_persists_after_path_migration_for_wifi_handoff` and
`token_persists_through_force_rotation_for_acid_reissue`.
Plan updated: 🟦 H3_CLOSED_CRITICAL_STREAM resolved; the
"limitation: tokens for actively-used DCIDs we migrated to" caveat is
removed from the §10.3 entry and from known-limitations item #5.
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
- Merge nested if statements in marmot stores' delete() and in
ZoomableContentDialog's MediaUrl* gating block (S1066).
- Replace `if (cond) false else x` with `!cond && x` in
ImageVideoDescription's effectiveStripMetadata (S1125).
- Remove unused `nip95description` local in FileServerSelectionRow.
All changes are body-internal with identical behaviour.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Peer's CONNECTION_CLOSE now transitions the connection through DRAINING
for 3 * PTO before flipping to CLOSED, instead of going straight to
CLOSED. While DRAINING:
- the writer emits no packets (drainOutbound returns null);
- the parser drops late inbound silently at the top of feedDatagramInner;
- close()-awaiters unblock immediately via closingDrainSignal so the
transition isn't gated on the 3*PTO grace.
After 3 * PTO the driver's send-loop timer fires
markClosedExternally("draining period elapsed") which transitions to
CLOSED. The §10.2.2 grace period gives the peer's last retransmits a
chance to converge before we discard state.
Implementation:
* `Status.DRAINING` enum value with kdoc tying it to §10.2.2.
* `QuicConnection.drainingDeadlineMs` + `enterDraining(reason, nowMs)`
(sets status, computes `now + max(3*pto, MIN_DRAINING_PERIOD_MS)`,
completes closingDrainSignal, fires qlog) + `isDrainingExpired`.
* Parser's CONNECTION_CLOSE handler routes through `enterDraining`
instead of `markClosedExternally`.
* Driver folds `drainingDeadlineMs` into its send-loop sleep
`withTimeoutOrNull` and transitions to CLOSED on expiry.
* Writer short-circuits drainOutbound for DRAINING (returns null —
spec MUST NOT send).
* Parser drops late inbound at the top of feedDatagramInner.
Updated `FrameRoutingTest.connection_close_from_peer_short_circuits_remaining_frames`
to expect DRAINING (was CLOSED). Other status=CLOSED assertions in the
test suite cover OUR-side closes (markClosedExternally on protocol
violations / TRANSPORT_PARAMETER_ERROR / FLOW_CONTROL_ERROR) which
still go directly to CLOSED.
Test: `DrainingStateTest` (7 cases) covers the peer-close → DRAINING
transition, late-inbound drop, deadline math, the
MIN_DRAINING_PERIOD_MS floor, retransmit no-op semantics, and the
fresh-connection invariant.
Plan updated to mark all 🟡 Medium items resolved. The 2026-05-09
audit's complete spec-compliance close-out: 2 of 2 High + 6 of 6
Medium fixed in seven commits.
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
A peer that has lost connection state (crash, restart, route change)
signals so by sending a "Stateless Reset" datagram — bytes shaped like
a short-header packet whose trailing 16 bytes equal a
`stateless_reset_token` previously communicated by the peer.
Pre-fix the tokens were stored (via NEW_CONNECTION_ID into the
[PathValidator] pool, and via the peer's `statelessResetToken`
transport parameter) but never matched against arriving datagrams —
a peer's stateless reset looked indistinguishable from noise and the
connection lingered until idle timeout, or worse, an attacker could
spam look-like-noise packets toward our integrity counter.
Implementation:
* `QuicConnection.isStatelessReset(datagram)` — short-header-form
+ size + trailing-16-bytes comparison. Matches against the peer's
advertised token AND every unused entry in `pathValidator`'s
pool. Constant-time per-token compare per §10.3.1 to avoid
leaking token bits via timing.
* `PathValidator.unusedTokenForSequence(seq)` — accessor for the
above to walk the pool.
* Parser pre-empts AEAD/HP parsing: `feedDatagramInner` checks every
short-header-form datagram before the loop. False-positive rate
of a real short-header packet (whose trailing 16 bytes are the
AEAD tag) matching a known token is 2^-128, negligible in
practice. Defense-in-depth: the AEAD-failure branch in
`feedShortHeaderPacket` retains a redundant check for
second-packet-of-coalesced edge cases.
* On match, `markClosedExternally("stateless reset received from
peer")` transitions silently to CLOSED — no CONNECTION_CLOSE
emission per §10.3.1.
Limitation: tokens for an actively-used DCID we migrated to via
`PathValidator.tryStartValidation` are lost when the entry leaves
the unused pool. Acceptable for the audio-rooms scope (no migration);
documented in the kdoc.
Test: `StatelessResetDetectionTest` (5 cases) covers token-match
silent-close, unknown-trailer no-close, pool-stored token match,
long-header form rejected, too-short datagram rejected.
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
Per-key AEAD usage limits per RFC 9001 §6.6 / §B.1:
* Confidentiality limit (encrypt count per send key):
AES-128-GCM = 2^23, ChaCha20-Poly1305 = 2^62. Reaching this means
AEAD security is no longer assured; the endpoint MUST initiate a
key update or close.
* Integrity limit (forged-packet count per receive key):
AES-128-GCM = 2^52, ChaCha20-Poly1305 = 2^36. Reaching this means
an attacker has been grinding for AEAD key recovery; MUST close
with AEAD_LIMIT_REACHED.
Pre-fix neither limit was tracked. Long-running AES-128-GCM sessions
(~2hrs at 1000pkt/s) could roll past the confidentiality limit; an
attacker spamming forged packets had no failure ceiling.
Implementation:
* `Aead.confidentialityLimit` / `Aead.integrityLimit` properties
surface the spec values per cipher; AES-128-GCM and
ChaCha20-Poly1305 (commonMain singletons + jvmAndroid JCA classes)
return the §B.1 numbers.
* `QuicConnection.aeadEncryptCount` / `aeadDecryptFailureCount` —
per-key counters, reset on every 1-RTT key rotation
(`commitKeyUpdate` and `initiateKeyUpdate`).
* Writer increments encrypt count after each application-level
build. At half the limit it soft-triggers `initiateKeyUpdate`
(latched via `aeadKeyUpdateRequested` so the in-flight rotation
isn't re-issued); at the limit it closes with AEAD_LIMIT_REACHED
if rotation hasn't completed.
* Parser increments decrypt-failure count on every 1-RTT AEAD
auth-tag failure; closes when the count hits the integrity limit.
Initial / Handshake levels are out of scope — their keys' lifetime is
too short to approach the limit.
Test: `AeadInvocationLimitTest` (6 cases) covers spec-value
verification, counter increment on application send, counter reset on
rotation, confidentiality-limit close, integrity-limit close (via a
real ciphertext-tampered datagram from the in-process pipe).
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
Once the peer has sent RESET_STREAM the receive side enters the "Reset
Recvd" terminal state per §3.2; any subsequent STREAM frame on that id
is a peer protocol violation and MUST close the connection with
STREAM_STATE_ERROR.
Pre-fix the parser silently absorbed the bytes — a peer that violated
the spec would leave us with a phantom mid-reset stream the peer
believed was already dead, with reset/byte bookkeeping diverging.
Implementation: a per-stream `peerResetReceived: Boolean` flag set in
the RESET_STREAM handler and checked at the top of the STREAM handler.
The flag is independent of our local-side `resetState` (which tracks
OUR RESET emission).
Test: `StreamAfterResetTest` (4 cases) covers STREAM-after-reset
closure, FIN-bearing STREAM-after-reset, the legal FIN-then-RESET
shape (no false-positive), and per-stream isolation (reset on stream 3
doesn't poison stream 7).
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
Pre-fix the receiver enforced ONLY per-stream `receiveLimit`. The
aggregate cap (`initial_max_data` / latest MAX_DATA) was advertised and
respected on the SEND side but never checked on the RECEIVE side — a
peer that opened many streams and pushed each up to its per-stream cap
could collectively exceed `initial_max_data` without us closing.
Implementation:
* `QuicStream.receiveHighestOffset`: per-stream high-water mark of
"largest stream offset received" — the spec quantity that gets
summed across streams for the connection-level check.
* `QuicConnection.connectionInboundOffsetSum`: running sum across
all streams of `receiveHighestOffset`. Updated in the parser at
STREAM and RESET_STREAM frame ingest time.
* Parser closes with FLOW_CONTROL_ERROR whenever the running sum
exceeds `advertisedMaxData`.
* RESET_STREAM final-size accounting: per §4.5 the finalSize counts
toward connection-level flow control even though no STREAM frame
delivered those bytes — a peer that resets a stream at a finalSize
larger than it had previously sent gets the extra bytes added to
the running sum at RESET arrival.
Different from the writer's MAX_DATA threshold logic (which uses the
cheaper contiguous-end approximation): the receiver-side enforcement
needs the strict spec quantity to close before bookkeeping diverges.
Test: `ConnectionLevelFlowControlTest` (5 cases) covers below-cap pass,
over-cap close, retransmit-doesn't-double-count, RESET_STREAM
finalSize counts toward limit, fresh-handshake invariants.
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
Five spec-compliance fixes from the 2026-05-09 audit, all in the same
"hostile-peer hardening" tier.
* RFC 9000 §18.2 — `applyPeerTransportParameters` now closes the
connection with TRANSPORT_PARAMETER_ERROR when the peer advertises
`max_udp_payload_size < 1200`, `ack_delay_exponent > 20`, or
`active_connection_id_limit < 2`. Pre-fix the values were decoded
but never bounds-checked.
* RFC 9000 §13.2.5 — the parser's ACK-delay decoding now uses the
PEER's advertised `ack_delay_exponent` (with the §18.2 default of 3
as the pre-handshake fallback) instead of our own config value.
Defensive coercion to 0..20 is preserved so a bypass of the bounds
check above can't desync the RTT estimator.
* RFC 9114 §7.2.4.1 — `Http3Settings.decodeBody` now rejects the
HTTP/2-reserved SETTINGS ids 0x02, 0x03, 0x04, 0x05 with
H3_SETTINGS_ERROR. Pre-fix they fell through to the generic
1<<32 cap and were accepted.
* RFC 9221 §3 — the writer now drops outbound DATAGRAM frames when
the peer didn't advertise `max_datagram_frame_size` (or advertised
0), or when the encoded frame (type byte + length varint + payload)
would exceed the peer's advertised value. Pre-fix the writer
emitted DATAGRAM regardless and let spec-conformant peers close us
with PROTOCOL_VIOLATION.
* Added `TransportParameterDefaults` for the §18.2 defaults
(ack_delay_exponent=3, max_ack_delay=25ms, active_connection_id_limit=2)
so callers don't hard-code the magic numbers.
Tests: `TransportParameterBoundsTest` (8 cases) drives a real handshake
through the in-process pipe and asserts CLOSED on each violation +
CONNECTED at the boundary; `Http3ReservedSettingsTest` (5 cases) covers
the four reserved ids and the adjacent legal ids. Plan tier dropped
from 🟡 Medium to resolved for all five items.
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
The two High-severity gaps from the 2026-05-09 four-RFC compliance audit.
Fixed-bit (RFC 9000 §17.2 long-header, §17.3 short-header): the spec
says fixed-bit (0x40) MUST be 1 in every v1 packet; receivers MUST
discard packets where it's 0. Pre-fix the parsers checked only the
form-bit (0x80) and accepted any fixed-bit value — a peer or off-path
attacker could route packets through AEAD that aren't valid v1 packets.
Both `parseAndDecrypt` paths and the `peekKeyPhase` shortcut now
silently drop fixed-bit=0. The bit isn't header-protected (HP only
XORs the low 5 bits), so the check runs on the raw wire byte before
HP unmask + AEAD. Test: `FixedBitValidationTest` (3 cases).
Idle timeout (RFC 9000 §10.1): `max_idle_timeout` was decoded into
config and advertised via the ClientHello transport-params extension,
but never enforced — a black-holed connection lived indefinitely.
This commit:
* adds `QuicConnection.lastActivityMs`, bumped on (a) successful
inbound packet decrypt and (b) outbound ack-eliciting send per
§10.1.1
* adds `effectiveIdleTimeoutMs()` returning the min of local and
peer advertisements (skipping any side that advertised 0), with
the §10.1 `3 * PTO` floor applied
* folds the idle deadline into the driver's send-loop
`withTimeoutOrNull` so an idle connection wakes exactly at expiry
* silently transitions to CLOSED via `markClosedExternally` per
§10.2.1 ("the connection enters the closing state silently —
discarding the connection state without sending a CONNECTION_CLOSE")
Test: `IdleTimeoutTest` (8 cases) covers the min-of-two computation,
0-means-disabled handling, the 3*PTO floor, deadline math, and
postpone-on-activity. Plan updated to mark both items resolved.
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
Plan had drifted ~2 weeks behind shipping work. Rewrote to reflect the
features that landed since 2026-04-26 (path validation, 0-RTT, key
update, ECN, session resumption, lock-split refactor, DoS hardening)
and added a fresh RFC compliance gaps section catalogued from a
four-agent audit (RFC 9000, 9001, 9002, 9221+9114+9204).
https://claude.ai/code/session_01XGmmaVuy2wsSZQx2AqN2ik
Round 2 of the blocking-code audit follow-ups. Both changes remove
commonMain synchronized blocks and replace polling with event-driven
suspension; :quic:jvmTest stays green on JVM and :quic:compileAndroidMain
passes for Android.
QuicStream.resetStream / stopSending
- Replace synchronized(this) double-checked init with
AtomicReference<ResetState?>.compareAndSet(null, …) (and same for
stopSendingState). The pattern is "first call wins"; CAS expresses
that directly without a lock.
- Backing fields converted from `internal var … = null` to
`internal val … = AtomicReference(null)`. The two readers in
QuicConnectionWriter switch to .load(); QuicConnectionWriter gains a
file-level @OptIn(ExperimentalAtomicApi::class).
- The @Volatile resetEmitPending / stopSendingEmitPending writes happen
only on the winning CAS path, so the writer reading the flag still
sees the populated state via volatile happens-before.
QuicConnectionDriver.close polling loop
- Replace `while (status == CLOSING) delay(1)` polling with a
CompletableDeferred<Unit> on QuicConnection (closingDrainSignal).
The deferred is completed at both transitions to CLOSED:
(1) drainOutbound after building the CONNECTION_CLOSE datagram, and
(2) markClosedExternally on its synchronized first-call-wins path.
- close() now awaits the deferred under the existing
CLOSE_FLUSH_TIMEOUT_MILLIS bound — same upper-bound semantics, no
1 ms wakeups during teardown. complete(Unit) is idempotent, so the
two transition sites racing each other is safe.
https://claude.ai/code/session_01CXTjnuHKCNXDmpfyKxgG3V
Audit of blocking and synchronized code in the QUIC module surfaced four
hot-path wins, all verified against :quic:jvmTest.
- PlatformCrypto: header-protection AES-ECB now uses a per-thread cached
Cipher. Previously every inbound and outbound packet paid for
Cipher.getInstance("AES/ECB/NoPadding") provider lookup. ThreadLocal is
safe because the call is stateless — every invocation re-init's with the
caller-supplied key.
- JdkCertificateValidator: gate the SAN-side InetAddress.getByName behind
looksLikeIpLiteral so a malformed cert with a hostname in a type 7 SAN
cannot trigger DNS resolution on the TLS validation path.
- QuicConnectionDriver.close: replace synchronized(this) double-checked
init with AtomicReference<Job?> + compareAndSet on a CoroutineStart.LAZY
job. Lock-free, removes a synchronized from commonMain, preserves the
original "first caller wins, second awaits same Job" contract.
- SendBuffer: mark _nextOffset, nextSendOffset, _finPending, _finSent,
_finAcked @Volatile and drop synchronized from their single-field
getters (nextOffset, sentOffset, finPending, finSent, finAcked). The
compound-formula readableBytes getter still synchronizes.
https://claude.ai/code/session_01CXTjnuHKCNXDmpfyKxgG3V
Move the feedDatagram KDoc below the MAX_QUIC_OFFSET const so it
attaches to the function declaration, and merge the duplicate KDoc
blocks above TlsResumptionState into a single block.
Round 13 — three architectural follow-ups + a closeout note.
* JdkCertificateValidator: ship a hand-picked Public Suffix List
subset covering the high-volume multi-label effective-TLDs
(multi-tenant ccTLDs and major hosting platforms). Pre-fix the
dot-count heuristic accepted `*.co.uk`, `*.s3.amazonaws.com`,
`*.github.io`, etc. — wildcards spanning these would impersonate
every co-tenant. The new MULTI_LABEL_PUBLIC_SUFFIXES set adds a
layer above the dot-count check; combined with the WebPKI / CT
ecosystem already requiring CAs to consult the full PSL when
issuing, this closes the practical attack surfaces. Full
~9000-entry PSL data shipping is still deferred (data-shipping
ask, doc'd); a domain not in the subset that's also a multi-label
ETLD remains a gap.
* JcaChaCha20Poly1305Aead: new JCA-backed implementation mirroring
JcaAesGcmAead's shape (cached Cipher + SecretKeySpec, range
overloads via Cipher.doFinal(input, off, len, output, outOff),
recent-nonce history for legitimate IV reuse on the
Initial-padding rebuild path). bestChaCha20Poly1305Aead(key)
expect/actual factory tries the JCA path first (Java 11+ /
Android API 28+) and falls back to the pure-Kotlin
ChaCha20Poly1305Aead singleton if the algorithm isn't available
(older Android, headless GraalVM native-image without the
standard providers). PacketProtectionBuilder routes the
ChaCha20-Poly1305 cipher suite through the factory instead of
the singleton. On supporting platforms this gives the same
outbound-allocation savings as round 8's AES-GCM range overload.
* QuicConnectionWriter: stop emitting fake ECN counts on ACK
frames. Pre-fix every 1-RTT ACK carried `AckEcnCounts(0, 0, 0)`
— claiming to track ECN while actually never reading inbound TOS
bits. RFC 9000 §13.4.2: "An endpoint that uses ECN MUST report
accurate ECN counts." Hardcoded zeros could be flagged as a
PROTOCOL_VIOLATION by strict peers cross-validating against
outbound packet counts; aioquic / picoquic / quic-go tolerate
it but other stacks may not. With ecnCounts = null we honestly
advertise "this endpoint isn't reporting ECN", peer skips its
own ECN-driven congestion logic for our direction. We still
mark outbound ECT(0) (other peers' tracking benefits from the
path-quality signal); RFC 9000 §13.4 allows the asymmetry.
* MutableSharedFlow migration for QuicStream.incoming declined as
obviated. The audit's suggestion was a workaround for the
cancel-coupling specifically (collector cancel → channel cancel
→ INTERNAL_ERROR) — round 11's `flow { for (c in
incomingChannel) emit(c) }` wrapper solved that. Switching to
MutableSharedFlow would change the semantics from "each byte to
exactly one consumer" (correct for stream bytes) to fan-out
(every emission to all collectors), which is wrong for QUIC
stream data.
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 40s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Round 12 — six smaller follow-ups across visibility, perf, and secret-handling.
* QuicStream.receiveDirtyForFlowControl gains @Volatile. The parser's
read-loop writes the flag and the writer's send-loop reads it
WITHOUT holding the same lock; without volatile the writer could
miss the parser's update for an unbounded time on JVM (the field is
hot in a drain loop where the JIT might cache it), suppressing
MAX_STREAM_DATA emissions until something else triggered a fresh
load.
* SendBuffer.readableBytes runs in O(1) instead of O(R) by maintaining
a cached `retransmitTotalBytes` counter. Updated in lockstep with
every retransmit deque mutation: addLast in [requeueAllInflight] +
the two paths in [removeOverlap] (RETRANSMIT zero-length + main
range), and add/removeFirst in [takeChunk]. Pre-flight "anything to
send?" check on the writer's hot path was previously walking the
deque per-stream per-drain.
* SendBuffer.requeueAllInflight coalesces adjacent ranges on insert.
Pre-fix the PTO probe path appended each in-flight range as a
separate retransmit entry, so on the next drain takeChunk emitted
one tiny STREAM frame per original-packet boundary. With
coalescing, contiguous bytes get replayed as one chunk + one AEAD
seal. FIN-bearing ranges stay separate (merging across a FIN
changes the implicit final-size invariant).
* TlsResumptionState dropped `data class`. The auto-generated
equals/hashCode used reference equality on its ByteArray fields
(PSK / ticket / peerTransportParameters), so two byte-identical
states compared unequal — almost never useful and a footgun for
caller-side caches. The auto-toString would dump PSK contents into
any log. Replaced with hand-written equals/hashCode using
contentEquals on the byte fields and a redacted toString that
reveals only sizes.
* QuicConnectionParser RESET_STREAM handler bounds finalSize at
[0, 2^62-1] per RFC 9000 §16 (the QUIC offset ceiling). Pre-fix
we accepted any varint, including values that could overflow
downstream Long math.
* PathChallenge/PathResponse IAE leak: re-traced and verified
non-issue. The decoder calls `r.readBytes(8)`, which either throws
QuicCodecException (short read) or returns exactly 8 bytes — the
constructor's `require(data.size == 8)` is unreachable from the
decode path. The audit was over-cautious; no code change.
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 39s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Round 11 — six follow-ups across perf, correctness, and API hygiene.
* QuicStream.incoming: replace `consumeAsFlow()` with `flow { for (c in
incomingChannel) emit(c) }`. Pre-fix the consume-style flow
cancelled the underlying Channel when the collector terminated,
which coupled "application stopped reading" with "parser
INTERNAL_ERRORs the connection on next delivery". The new emit-only
flow leaves the channel open across collector cancellation, so
applications can stop reading temporarily and resume later
(sequential collects, not concurrent — that's still a race on the
channel iterator).
* RFC 9001 §6.1 client-initiated key update: the existing
[QuicConnection.initiateKeyUpdate] no longer requires the caller
to enforce spec invariants. Returns false if the handshake isn't
yet complete (§6.5: MUST NOT initiate before HANDSHAKE_DONE) or if
a previous rotation is still in flight (§6.4: MUST NOT initiate a
subsequent update until the previous one is confirmed). The parser
clears the [keyUpdateInProgress] flag on the first inbound packet
that AEAD-decrypts under the post-rotation live keys — the
confirmation signal that the peer has rolled forward.
* Aead.sealInto: new range + in-place seal that writes ciphertext+tag
DIRECTLY into a caller-supplied output buffer at a given offset.
Default impl falls back to sealRange + copy; JcaAesGcmAead overrides
to use Cipher.doFinal(input, inOff, inLen, output, outOff).
LongHeaderPacket.build / ShortHeaderPacket.build now pre-allocate
the final packet buffer in a single shot and have the AEAD write
ciphertext+tag in-place. Pre-fix every outbound packet allocated
4 ByteArrays (headerBytes, paddedPlaintext, ciphertext, concat
buffer); now ~2 (the final packet + the AEAD provider's internal
scratch).
* QuicConnectionWriter.drainOutbound: skip the
`active.sortedByDescending { priority }` allocation when EVERY
active stream shares the same priority — not just the
default-zero case. A homogeneous priority-7 workload now keeps
insertion order at no cost.
* QuicConnection.scratchAppFrames / scratchAppTokens: per-connection
reusable lists for buildApplicationPacket. Cleared at function
entry, re-used across drains under streamsLock's single-writer
guarantee. The tokens list is `.toList()`-snapshotted into the
SentPacket record before reuse, so retransmit dispatch is
unaffected. NOT applied to collectHandshakeLevelFrames because
its returned [HandshakeLevelContents] is held across two
buildLongHeaderFromFrames calls (natural-size + padded rebuild)
in drainOutbound.
* Removed dead `parts = mutableListOf<ByteArray>()` declaration at
the top of drainOutbound — never referenced; the actual datagram
assembly uses inline `listOfNotNull(...)` instead.
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 43s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Round 10 — supersedes the typed-exception approach from round 9.
Round 9 introduced [PskRejectedException] as a "punt to the application
layer" hack, with a comment claiming the in-place fallback was too
subtle to land safely. After tracing the actual derivation path the
fix turns out to be one line.
The key observation: the on-wire ClientHello (with `pre_shared_key`
extension and binder bytes) goes into BOTH client and server
transcript hashes regardless of accept / reject (RFC 8446 §4.2.11).
The transcript hash itself doesn't need any rebuild. The ONLY thing
that differs between accept and reject is how [earlySecret] is
derived:
* accepted: HKDF-Extract(0, PSK)
* rejected: HKDF-Extract(0, 0) ← same as no-resumption path
So when the server returns ServerHello without `pre_shared_key`,
we simply call `keySchedule.deriveEarly()` to overwrite the
PSK-derived [earlySecret] with the zero-keyed value. [deriveHandshake]
runs immediately after with the new earlySecret + ECDHE shared
secret, and the handshake proceeds along the regular non-resumption
path (which is well-tested by every non-resumption test in the
suite).
* `pskAccepted = false` so the
WAITING_CERTIFICATE_OR_FINISHED state correctly demands
Certificate + CertificateVerify (a Finished without those would
still be rejected as unauthenticated).
* Any 0-RTT packets the application emitted under the
PSK-derived [clientEarlyTrafficSecret] are lost — server can't
decrypt them and EncryptedExtensions arrives without the
early_data extension, so [earlyDataAccepted] = false. The
application layer is responsible for replaying any 0-RTT-bound
payload over 1-RTT. The handshake itself proceeds cleanly.
* [PskRejectedException] (added in round 9) deleted as dead code.
[QuicCodecException] reverts to a `final` class.
All 269 :quic:jvmTest tests pass. The fallback re-uses the
deriveEarly() codepath that every non-resumption test exercises,
so test coverage is implicit in the existing suite.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Round 9 — the two largest items remaining from the audit.
* RFC 9002 §6.1.2 timer-driven loss detection. [detectAndRemoveLost]
now returns a [Result] data class carrying both the list of lost
packets and the absolute monotonic deadline at which the next
earliest sub-largest in-flight packet will cross the time threshold.
The parser stores that deadline on each [LevelState.nextLossTimeMs]
per encryption level, and the driver's send loop now sleeps for
`min(ptoDeadline, minNextLossTimeAcrossLevels) - now`. On expiry,
the driver distinguishes:
* Loss-timer wake → run [detectAndRemoveLost] across all levels;
declare time-threshold-lost packets and dispatch their tokens.
No probe budget, no exponential backoff.
* PTO wake → existing [handlePtoFired] path (probe + backoff).
Pre-fix tail loss waited for the full PTO (often 5x the time
threshold) before retransmitting because we had no event between
ACK arrivals to fire loss detection. Now `9/8 * max_rtt` is the
ceiling.
* TLS PSK rejection: instead of the prior generic [QuicCodecException]
("server rejected PSK; full-handshake fallback not implemented"),
raise a typed [PskRejectedException] subclass. Application reconnect
logic can selectively catch this and retry the handshake without
cached resumption state — a path that's correct by construction
(fresh ClientHello, no PSK history, no transcript-rebuild
complexity). [QuicCodecException] is now `open` so the subclass
can extend it.
In-place fallback (clear early secret, rebuild transcript without
PSK extension, replay derivation) remains deferred — the subtle
transcript-hash discrepancies it could introduce would be much
harder to debug than a hard failure that the application
intentionally turns into a retry.
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 47s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Round 8 — AEAD allocation reduction on the receive hot path, plus the
documentation of two known-fragile-but-not-broken couplings.
* Aead gains [openRange] / [sealRange] taking (array, offset, length)
triples for AAD and plaintext/ciphertext. Default impls slice and
delegate to the existing whole-array methods so non-JCA AEADs
(Aes128Gcm singleton, ChaCha20Poly1305Aead) still work. The
JCA-backed [JcaAesGcmAead] overrides both, passing offsets straight
to `Cipher.updateAAD(byte[], offset, len)` and
`Cipher.doFinal(byte[], inputOffset, inputLen)` — JCA accepts ranges
natively and does no internal copies. Saves ~2 KB ByteArray
allocations per inbound packet (one for the header `aad`, one for
the `ciphertext`) — at audio-room receive rates (~100 packets/sec)
that's ~12 MB/min of GC churn eliminated. Same overload on the
outbound path is wired but currently exercised less because the
build path constructs `headerBytes` and `paddedPlaintext` as
separate fresh allocations.
parseAndDecrypt in both ShortHeaderPacket and LongHeaderPacket now
call openRange instead of slicing into intermediates.
* JdkCertificateValidator.dnsMatches: explicit doc note on the
public-suffix-list gap. The dot-count heuristic accepts wildcards
like `*.co.uk` / `*.github.io` / `*.s3.amazonaws.com` whose effective
TLD spans multiple labels. WebPKI / CT logging mitigates this in
practice (CAs validate against the actual PSL), but our local
validation alone wouldn't catch a rogue cert. Production callers
for sensitive endpoints should rely on OS / NetworkSecurityConfig
pinning rather than QUIC's hostname check alone. Full PSL data
shipping deferred until justified.
* QuicStream.incoming: explicit doc note on the single-collector
contract. [consumeAsFlow] cancels the underlying [Channel] when
its collector terminates, and once cancelled the parser's next
trySend fails, sets [overflowed] = true, and the parser tears down
the connection with INTERNAL_ERROR. Production callers already
follow single-collector + collect-until-FIN, but the doc lays out
the rule so a future refactor doesn't loosen it accidentally.
Long-form discussion of the `MutableSharedFlow` alternative and
why we declined it.
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 40s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Round 7 — closing out the audit's spec/correctness/perf quick wins.
* WtPeerStreamDemux: validate peer SETTINGS includes ENABLE_WEBTRANSPORT=1
AND ENABLE_CONNECT_PROTOCOL=1 (draft-ietf-webtrans-http3 §3 +
RFC 8441). Pre-fix we accepted any SETTINGS and proceeded to
Extended CONNECT, which the server then rejects with no
diagnostic for the application. Now surfaces as a typed protocol
error on peerH3ProtocolError so the QUIC layer closes deliberately.
* QpackEncoder: set N=1 (never-indexed) on literal field lines for
authorization / cookie / set-cookie / proxy-authorization per
RFC 9204 §4.5.4. Pre-fix sensitive credentials could be cached
by intermediate QPACK encoder caches.
* QuicConnection.getOrCreatePeerStreamLocked: track peerInitiated*Count
via max(current, peerIndex+1) instead of += 1. The counter now
derives from the stream id's index field (RFC 9000 §2.1) and is
idempotent against retransmits-after-eviction. Pre-fix a peer
retransmit on a stream id that aged out of the retired-IDs FIFO
bumped the counter again, eventually triggering spurious
MAX_STREAMS_* emissions.
* applyPeerRetireConnectionIdLocked: reclassify the close-on-seq=0
case as PROTOCOL_VIOLATION (peer fault) instead of INTERNAL_ERROR
(our fault). The diagnostic was misleading — the peer IS
misbehaving (asking us to retire our only SCID with no
replacement available), not us.
* QuicConnectionWriter.drainOutbound: skip the
`streamsView.filter { !it.isClosed }` allocation when no streams
are closed. Quick `any` scan first; only allocate the filtered
list when at least one stream is actually closed. Saves an
N-sized ArrayList per drain in the common case (~50 drains/sec
× N up to ~2000 streams under multiplex load).
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 40s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Pre-fix QpackHuffman.decode allocated two boxed Integers per output
character: one for the `candidate` Int passed into
`HashMap<Int, Int>.get` and one for the wrapper-Integer return value.
Output also went through `ArrayList<Byte>`, boxing every emitted
byte as a `java.lang.Byte` (~16 bytes per output byte on a 64-bit
JVM). On a typical HTTP/3 response with ~30 header values, that's
hundreds of throwaway wrapper objects per request — pure GC churn
on the hot path.
The new layout keeps two parallel `IntArray`s per code-length:
codes[len] (sorted ascending) and syms[len] (the matching symbol
indices). Lookup is a primitive `IntArray.binarySearch(candidate)`
— no boxing, the array stays in JIT-friendly contiguous memory,
and the per-length arrays are tiny (a few entries each, since the
Huffman table is sparse at any given length).
Output uses a growable `ByteArray` with a manual position index
rather than `ArrayList<Byte>`. Pre-grow to 2× input size as a
rough upper bound — ASCII headers compress to ~62% with HPACK
Huffman, so we rarely need to grow.
Also fixes a latent bug: the new init loop covers lengths 5..30
(previously 5..29), restoring decoding for symbols 10 (LF), 13
(CR), 22 (DC2) which all use 30-bit codes per RFC 7541 Appendix B.
Pre-rewrite the HashMap path included these via `for (sym in 0..255)`
walking the full symbol table; the IntArray rewrite needed an
explicit length range and accidentally cut at 29. Added a unit
test exercising hand-encoded length-30 inputs to lock the fix in.
Behavior verified against RFC 7541 Appendix C test vectors and the
new length-30 round-trip. All 269 :quic:jvmTest tests pass.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
When a Namecoin record's value isn't valid JSON (a real failure mode
when an operator hand-builds the value and miscounts braces), the
NIP-05 path used to silently swallow the parser exception and surface
a misleading "no nostr field" message. That sends the publisher
chasing a phantom missing field when the actual problem is the value
itself.
Concrete case that triggered this: a `name_update` published a
474-byte d/testls value with one closing brace short of balanced. The
string parses up to the missing brace, after which kotlinx.serialization
throws "Unfinished JSON term at EOF at line 1, column 474". That error
was previously dropped, leaving the operator to debug "no nostr field"
without ever seeing the underlying JSON parse failure.
Changes:
- New NamecoinResolveOutcome.MalformedRecord(name, error). Distinct
from NoNostrField. The `error` field is the parser's own diagnostic
(e.g. "Unfinished JSON term at EOF at line 1, column 474") so the
publisher can locate the broken byte without spelunking.
- NamecoinNameResolver.performLookupDetailed: parse via a new
parseValueOrError helper and surface MalformedRecord instead of
collapsing into NoNostrField. Also rejects non-object top-level
values (arrays, primitives, null) with a useful diagnostic
("top-level value is JsonArray, expected JSON object").
- DesktopSearchScreen handles the new outcome by surfacing the parser
error verbatim in the Namecoin status banner, so the column number
reaches the publisher's screen.
Tests (commonTest / NamecoinImportTest):
- "NIP-05 lookup surfaces MalformedRecord with parser detail when
value is broken JSON": a deliberately one-brace-short value yields
MalformedRecord with a non-empty diagnostic.
- "NIP-05 lookup surfaces MalformedRecord when top-level value is a
JSON array": ensures non-object top-level values are rejected with
a useful "expected JSON object" message rather than silently
parsing as something unusable.
Tests don't pin the exact parser wording (kotlinx.serialization can
change it across versions); they only pin that the message is
attributed to JSON parsing rather than to a missing field.
Round 5 of the audit follow-ups. The remaining low-leverage items
from the original audit all addressed in one pass.
* PathValidator: pick the smallest spare CID sequence number rather
than LinkedHashMap insertion order. RFC 9000 §19.15 lets the peer
issue NEW_CONNECTION_ID out of sequence (e.g. retransmits arriving
after newer offers); insertion-order picking would land on
whichever offer arrived first instead of the lowest seq, drifting
away from the RFC-expected ordering. forceRotateToHigherSequence
also now filters >= retirePriorToWatermark explicitly so we never
pick a sequence below the watermark even if the pool somehow holds
one.
* QuicWebTransportSessionState.close: driver.wakeup() AFTER enqueuing
the WT_CLOSE_SESSION capsule + FIN but BEFORE driver.close, so the
capsule actually reaches the wire instead of being short-circuited
by the driver shutdown. Pre-fix the peer saw an abrupt UDP-level
tear-down with no application-error-code surfaced.
* QuicStream.resetStream / stopSending: synchronized(this) atomic
CAS for the "first call wins" gate. Pre-fix two concurrent callers
could both observe `resetState == null` and both write — the
second caller's errorCode would clobber the first while
resetEmitPending was already set, so the writer emitted the
RESET_STREAM with whichever value landed last.
* Http3Settings.decodeBody: per-id value range checks. A peer that
advertises e.g. MAX_FIELD_SECTION_SIZE = 2^60 could otherwise
drive our encoder into unbounded heap. Bounds chosen above any
legitimate value (1 GiB for table-capacity / field-section caps,
1 for boolean flags) and below 2^32 for unknown ids.
* Privatize crypto-relevant static byte arrays:
InitialSecrets.V1_INITIAL_SALT, RetryPacket.V1_RETRY_KEY,
RetryPacket.V1_RETRY_NONCE. Pre-fix these were public mutable
ByteArrays — any caller could stomp on them, and any toString /
reflection would leak the bytes. Crypto material doesn't need to
be reachable outside the deriving / sealing path.
* peekHeader length cast: re-verified as already safe (lengthRaw is
bounded by r.remaining before .toInt() — Int.MAX_VALUE ceiling
enforced).
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 2m 17s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Round 4 of the audit follow-ups.
* Reserved-bit enforcement on unmasked QUIC headers (RFC 9000 §17.2 /
§17.3.1). Pre-fix the parser silently accepted long-header packets
with bits 0x0C set or short-header packets with bits 0x18 set after
HP unmasking — the spec mandates PROTOCOL_VIOLATION close. Added
[QuicProtocolViolationException] and a top-level catch in
feedDatagram that translates the throw into markClosedExternally.
Long-header parse also drops a now-dead `if form==1` branch on the
first-byte mask: we already early-returned in non-long paths above,
so the mask is always 0x0F.
* TLS handshake-message bounds:
- TlsCertificateChain.decodeBody: reject `listLen > r.remaining`
up front; assert `r.position == end` after the cert loop.
Without this, a malicious peer could push us into reading past
the message limit on per-cert extensions.
- TlsServerHello.decodeBody / TlsEncryptedExtensions.decodeBody:
reject trailing bytes after the extensions block.
- TlsEncryptedExtensions.alpn: enforce RFC 7301 §3.1 (server
returns EXACTLY one protocol_name); validate outerLen matches
remaining and reject multi-name responses.
* SendBuffer.data shrink: pre-fix the doubling-on-grow buffer never
shrank, so a stream that ever held N bytes pinned `data.size = N`
for the connection's lifetime. Long-tail memory retention on
per-stream basis. advanceFlushedFloorIfPossible now releases
capacity once live bytes occupy ≤ 1/4 of the allocation, shrinking
to max(SHRINK_FLOOR_BYTES=4096, 2*dataLen). Below the floor the
doubling cost is negligible; above it the multi-MiB transients
release back to the heap.
All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 47s.
https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM
Claude