Resume a prior TLS session in the QUIC handshake

[ydnar]

Motivation:

A QUIC client reconnecting to a server it has spoken to before can resume the prior TLS session instead of running a full handshake — an abbreviated exchange keyed on a pre-shared secret, with no certificate chain to re-send and verify (RFC 8446 § 2.2, RFC 9001 § 4.6). A TLS 1.3 server issues session tickets after the handshake (RFC 8446 § 4.6.1); the client keeps them and offers one on a later connection to that server.

The swift-nio-ssl fork surfaces this through NIOSSLQUICHandshake (alta/swift-nio-ssl#19); this PR drives it through the QUIC stack, so a real QUICConnection resumes.

Modifications:

TLSHandshake adopts the fork's resumption API — it offers a stored session, captures the server's post-handshake tickets (takeNewSessions()), and reports sessionReused — picking up the reordered NIOSSLQUICHandshake initializer and its new earlyDataRejected state along the way.

Above it, a client session store mirroring the NEW_TOKEN tokenStore. QUICSessionStore (protocol + the built-in bounded-LRU QUICInMemorySessionStore, single-use popSession per RFC 8446 § 4.2.11 anti-replay) hangs off QUICConfiguration.clientSessionStore, keyed by the server dialed — the SNI hostname or the address (a shared QUICServerKey, the Key of both stores). The offer is popped on connect and threaded through makeCore into the handshake at construction, since the session must reach TLS before the ClientHello; the capture side mirrors tokenStore — the server's ticket is drained from the core and cached in DatagramHandler.deliver.

Package.swift / Package.resolved pin the fork's main at #19's merge commit; they tracked the quic-session-resumption branch while #19 was in review, so this PR's CI could build against the unmerged API.

Validation: TLSHandshakeTests.resumesACapturedSession and TransportSimulatorTests.sessionResumption capture a ticket on a first connection and assert the second handshake is abbreviated (sessionReused / didResumeSession); the resumption interop case runs it end to end (added to supportedTestCases and the CI matrix, with the negative 127-guard removed). docs/PLAN.md and TRACEABILITY.md record it.

Result:

Client TLS session resumption works end to end through the public API, opt-in via QUICConfiguration.clientSessionStore, and the runner's resumption case passes. 0-RTT early data — the fork's Resumption API is already in place for it — is the follow-up.

🤖 Generated with Claude Code

[ydnar]

LGTM

[ydnar]

Would there ever be a QUICServerSessionStore type? If not, can we trim the Client part of the name?

[ydnar]

Similarly if there will never be a QUICInMemoryServerSessionStore, then let’s omit the Client part of the name.

[ydnar]

Thanks — all addressed in fed9e85:

• .map → if-expression (ConnectionCore): a ternary would force-unwrap the optional, so it reads let resumption: NIOSSLQUICHandshake.Resumption = if let resumeSession { .resume(session: resumeSession) } else { .none }.
• Client in the type names: dropped — no QUICServerSessionStore is planned. A server resumes transparently, validating the client's ticket against its own key, so there's nothing to configure on that side. Now QUICSessionStore / QUICInMemorySessionStore / QUICSessionStoreKey; kept QUICConfiguration.clientSessionStore per your note on line 119.
• resumptionSession → resumeSession across the offer path.
• Key nested under the store: a Swift protocol can't contain a nested concrete type, so it stays a top-level QUICSessionStoreKey surfaced as QUICSessionStore.Key through the protocol's typealias Key — call sites can write QUICSessionStore.Key, the same shape as QUICTokenStoreKey.
• fileprivate(set) vs private(set): the setter runs from RoutingCore.registerDialed, which lives on the enclosing RoutingCore, not on the nested RoutedConnection. private(set) scopes the setter to RoutedConnection and its same-file extensions, so RoutingCore couldn't reach it — it wouldn't compile. Left fileprivate(set), matching the tokenStore / tokenStoreKey fields two lines up.

---

Generated by Claude Code

[ydnar]

Done in 904ab3f — merged both into one QUICServerKey (Sources/NIOQUIC/QUICServerKey.swift), now the Key typealias of both QUICTokenStore and QUICSessionStore. Of your three, QUICServerKey is the most accurate: QUICSessionKey would mislead since the token store shares it, and QUICAddressKey names the mechanism (hostname or address) rather than the meaning — both caches key on which server the client dialed.

---

Generated by Claude Code

[ydnar]

Merge when green.