Session tickets or session IDs for resumption: which scales, and which leaks?

Session tickets or session IDs for resumption: which scales, and which leaks?

What actually gets reused when a TLS session resumes? The two classic mechanisms store the secret in different places, and that placement is the whole tradeoff.

Session-ID resumption (the TLS 1.2 model) keeps the session state in a server-side cache keyed by an ID. It is stateful: every terminator in a pool must share the cache or resumption fails on the wrong node. That coordination cost is why large fleets disliked it.

Session tickets (RFC 5077) move the encrypted state to the client. The server holds only a Session Ticket Encryption Key (STEK); the client presents the ticket on return. This is stateless and scales horizontally — but a long-lived, shared STEK is a forward-secrecy liability. If it leaks, every session encrypted under it is exposed, defeating ephemeral key exchange.

TLS 1.3 folds both into PSK (Pre-Shared Key) resumption via NewSessionTicket, and adds single-use tickets to limit linkability.

— Rotate STEKs aggressively (hours, not weeks) to preserve forward secrecy.
— Prefer tickets for stateless scaling, but never let the STEK go stale.
— On TLS 1.3, lean on single-use PSK tickets to cut tracking.

Further reading: RFC 5077; RFC 8446 §2.2 and §4.6.1.

Bottom line: tickets win on scale, but a poorly rotated STEK quietly destroys the forward secrecy you paid for.