<b>What actually happens when a TLS 1.3 session ticket fails to resume?</b>

<b>What actually happens when a TLS 1.3 session ticket fails to resume?</b>

TLS (Transport Layer Security) 1.3 offers two resumption paths via PSK (Pre-Shared Key): the standard 1-RTT mode and 0-RTT early data. When a ticket is rejected, the mechanism is not a failure but a fallback, and understanding the branch point matters.

The client sends its PSK identity in the ClientHello extension (RFC 8446, §4.2.11). If the server cannot decrypt the ticket — expired key, rotated STEK (Session Ticket Encryption Key), or unknown identity — it simply omits the pre_shared_key extension from its ServerHello. The client detects the absence and silently transitions to a full handshake, negotiating fresh keys via the key_share extension.

The subtle cost is 0-RTT early data. If the client gambled and sent application data in the first flight, that data is rejected (the server signals via the absence of the early_data extension in EncryptedExtensions). The client MUST be prepared to retransmit it over the freshly negotiated keys. This is why 0-RTT is unsafe for non-idempotent requests — RFC 8446 §2.3 and §8 warn explicitly about replay.

Evidence vs. speculation: the spec mandates the fallback; what varies in practice is how aggressively servers rotate STEKs (often hourly), which is the dominant cause of resumption misses in the wild.

<b>Further reading:</b> RFC 8446 §2.2, §2.3, §4.6.1.

<b>Bottom line:</b> A rejected ticket degrades gracefully to a full handshake; the real hazard is unconfirmed 0-RTT data, which the application layer — not TLS — must be designed to replay safely.