How do you tune TLS 1.3 session resumption across a server fleet without leaking forward secrecy?

How do you tune TLS 1.3 session resumption across a server fleet without leaking forward secrecy?

Resumption via PSK (pre-shared key) tickets, RFC 8446 section 4.6.1, lets a returning client skip the full handshake. Done wrong across many servers, it either fails (each box has its own keys) or undermines forward secrecy (shared static keys). Tuning playbook.

— Decide the model: stateless tickets (server encrypts session state into a ticket) scale across a fleet but require a shared ticket-encryption key, which becomes a single point of secrecy.
— Rotate that ticket key frequently (hours, not weeks) and keep only a short overlap window, so a stolen key exposes a bounded slice of past sessions.
— Never distribute a static, never-rotated ticket key across servers; that retroactively breaks forward secrecy for every resumed session.
— For resumption to work behind a load balancer, all nodes must share the current and previous ticket keys; synchronize via a secret store, not a config file in git.
— Combine resumption with (EC)DHE in the PSK handshake so each resumed session still derives fresh key material.

Evidence vs. speculation: rotation cadence directly bounds exposure; this is arithmetic, not opinion.

Further reading: RFC 8446 sections 2.2 and 4.6.1; RFC 5077 (the stateless-ticket lineage).

Bottom line: short-lived, fleet-synced ticket keys preserve both resumption speed and forward secrecy.