Lays groundwork for full 0-RTT without yet diverging the writer's
application-packet build. Three additive pieces:
- TlsResumptionState carries maxEarlyDataSize (parsed from
NewSessionTicket's early_data extension) + peerTransportParameters
+ negotiatedAlpn from the prior connection. RFC 9001 §7.4.1
requires a 0-RTT-sending client to use the REMEMBERED transport
params (flow-control windows, stream caps) when sending 0-RTT
data, since the new connection's ServerHello hasn't arrived yet.
- TlsClient.start, on resumption with maxEarlyDataSize > 0:
derive client_early_traffic_secret via the new
TlsKeySchedule.deriveEarlyTraffic + post-CH transcript snapshot,
surface via secretsListener.onEarlyDataKeysReady. Resumption
ClientHello now also includes the empty `early_data` extension to
opt into 0-RTT.
- QuicConnection has zeroRttSendProtection slot installed in
onEarlyDataKeysReady and cleared in onApplicationKeysReady (RFC
9001 §4.10 — 0-RTT keys MUST NOT be used after 1-RTT installed).
Remaining: writer's buildApplicationPacket needs a dual 0-RTT
long-header (type=0x01) / 1-RTT short-header path; remembered
transport params have to land before any pre-handshake stream
creation so credit is available; EE accept/reject signal must
trigger re-send when the server declines. None of those are wired
yet — this commit is just the TLS-side foundation. 334 unit tests
pass, no behaviour change for non-resumption / non-0-RTT
connections.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vitor Pamplona
b736a953ef