<b>What actually distinguishes a session ticket from a session ID in TLS 1.3?</b>

<b>What actually distinguishes a session ticket from a session ID in TLS 1.3?</b>

A precise question, because TLS 1.3 (RFC 8446) collapsed the older RFC 5077 ticket mechanism and RFC 5246 session-ID caching into a single construct: the pre-shared key (PSK).

In TLS 1.2, two resumption paths coexisted. Session IDs required the server to keep per-session state in a cache. Session tickets (RFC 5077) externalized that state, encrypting it under a Session Ticket Encryption Key (STEK) the client stored opaquely.

TLS 1.3 keeps only the ticket model, but renames it. After the handshake, the server sends one or more NewSessionTicket messages. Each carries a PSK identity and a ticket_nonce; the actual resumption secret is derived via HKDF (HMAC-based Key Derivation, RFC 5869) from the resumption master secret plus that nonce. So two tickets from one connection yield distinct PSKs.

The practical consequence: resumption no longer reuses a literal key. It derives a fresh one per ticket. This matters for forward secrecy — though note that a PSK-only resumption without the optional psk_dhe_ke (Diffie-Hellman) mode sacrifices forward secrecy for the resumed session.

Further reading: RFC 8446 §4.6.1, RFC 5077, RFC 5869.

Bottom line: TLS 1.3 has one resumption primitive (the PSK), derived per-ticket via HKDF; the session-ID cache is gone.