TLS 1.3 Pre-Shared Key (PSK) and Ticket-Based Session Resumption Architecture
Learn how TLS 1.3 uses a pre-shared key from an earlier connection for session resumption and how tickets support that process. Optional 0-RTT early data can be replayed, so its impact and application-level handling need separate consideration.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Handshake round trips and cryptographic work depend on the TLS version, key-exchange mode, resumption, and network conditions. It is therefore inaccurate to say that every full handshake necessarily takes one or two RTTs or causes a particular TTFB penalty. Session resumption can use a PSK established by an earlier connection to reduce work in a later handshake; optional 0-RTT early data has separate replay risks.
1. TLS 1.3 Unified Pre-Shared Key (PSK) Mechanics and NewSessionTicket Structure
TLS 1.3 can use a pre-shared key (PSK) for resumption. After a handshake, a server may send a NewSessionTicket; client and server can use the resulting ticket information in a later connection. RFC 8446 specifies that the client offers a PSK identity and binder in ClientHello and that the server decides whether to accept it. Ticket contents and key protection are implementation details, so the RFC does not justify claiming that every server encrypts the same fields in a ticket with a dedicated ticket-encryption key.
2. 0-RTT early data and replay risk
TLS 1.3 can use an earlier session’s PSK to send early data before the handshake completes, but resumption itself does not require 0-RTT: a resumed PSK connection can send application data after completion. RFC 8446 says 0-RTT can be replayed and does not provide forward secrecy. Do not send state-changing operations or actions whose duplicate execution would cause harm as early data, and do not assume TLS prevents duplicate processing. The RFC also distinguishes PSK-only from PSK combined with (EC)DHE, which has different forward-secrecy properties; resumption does not necessarily remove all public-key work or authentication checks.
Cloudflare's TLS 1.3 explanation illustrates how a server using session tickets may not know that it has already processed an early-data request, and recommends limiting early data to operations that do not change state. RFC 8446 likewise tells application protocols to assess replay safety and not use 0-RTT without an appropriate profile. Do not assume every GET is automatically safe: review side effects, duplicate execution, and replay handling across servers for the actual route. If the risk is unclear, disable early data for that operation and process it after the handshake.
RFC 8446 also constrains when a server may accept early data: it must accept a PSK cipher suite, select the first offered PSK, and verify associated parameters such as the TLS version, cipher suite, and ALPN. Even when those checks succeed, the application must handle replay risk. A route may use an application-level idempotency key or duplicate suppression if its state model supports that design; operations that cannot tolerate replay should wait for the ordinary handshake path. Ticket acceptance, early-data acceptance, and application authorization are separate decisions.
3. Review early data per operation
For an operational review, record session resumption and 0-RTT as separate settings, then compare full and resumed handshakes under the same conditions. Observe ticket issuance and PSK selection, but do not infer an implementation’s ticket-key management from the TLS specification alone. Performance measurements do not establish replay safety.