TLS 1.3: 0-RTT, Early Data, and Session Resumption

TLS 1.3 (RFC 8446, 2018) redesigned the TLS handshake to reduce latency and remove legacy cruft. A full TLS 1.3 handshake completes in 1-RTT: the client sends ClientHello with supported key_shares (ephemeral ECDH public keys) in the first flight; the server responds with ServerHello, its key_share, encrypted extensions, certificate, and Finished — all in one response. The client sends its Finished and can immediately send application data. Compared to TLS 1.2's 2-RTT handshake, this halves connection setup time for new sessions.

TLS 1.3 uses HKDF (HMAC-based Key Derivation Function) with a structured key schedule. After the ECDHE key exchange, the shared secret feeds into a hierarchy: Extract(early_secret, DHE) -> handshake_secret; then Extract(handshake_secret, 0) -> master_secret. From these, HKDF-Expand-Label derives separate keys for client and server handshake traffic, application traffic, and resumption. The clean separation ensures that compromising one layer of keys does not affect others — a significant improvement over TLS 1.2's more ad-hoc PRF-based key derivation.

TLS 1.3 session resumption uses Pre-Shared Keys (PSKs) derived from previous sessions. After a completed handshake, the server sends a NewSessionTicket message containing a PSK identity and a ticket value (an encrypted blob holding the resumption secret). On reconnect, the client includes the PSK identity in ClientHello. If the server recognizes it, both sides derive a new session key from the PSK plus fresh ECDHE, achieving 1-RTT resumption with forward secrecy. The ticket has a configurable lifetime (typically 24 hours) and should be encrypted with a rotating server-side key.

TLS 1.3 allows 0-RTT early data for resumed sessions. The client uses the PSK from a previous session to encrypt application data that is sent in the first flight — before any server acknowledgment. This eliminates one round trip for connections to previously visited servers, providing near-zero latency for repeat connections. The server advertises 0-RTT support in the NewSessionTicket via the early_data extension with a max_early_data_size. The server must have a mechanism to accept or reject 0-RTT data and signals acceptance in EncryptedExtensions.

0-RTT data has a fundamental security limitation: it is vulnerable to replay attacks. An on-path attacker who captures the first flight can replay it to the server, causing the server to process the early data again. This is inherent — the server has not yet sent any message, so there is no server-contributed freshness. Mitigations: (1) Single-use tickets (the server invalidates a ticket after first use, using a distributed cache like memcached/Redis). (2) Time-bound tickets (reject 0-RTT after a short window, e.g., 5 seconds). (3) Application-level idempotency (only allow 0-RTT for safe GET-equivalent operations).

The most robust 0-RTT anti-replay mechanism is single-use session tickets. The server maintains a "used ticket" store (a distributed cache in multi-server deployments). When 0-RTT data arrives, the server checks if the ticket has been seen before — if yes, it rejects early data and falls back to 1-RTT. If no, it marks the ticket as used and processes early data. For correctness, all servers in a cluster must share the used-ticket cache. Redis with short TTLs (matching ticket lifetime) is a common implementation. Without this mechanism, 0-RTT is unsafe for non-idempotent operations like payments.

TLS 1.3 PSK resumption without DHE lacks forward secrecy for the resumed session — if the PSK is later compromised, all resumed session traffic can be decrypted. To maintain forward secrecy, TLS 1.3 supports PSK-with-DHE: the ClientHello includes both a PSK identity and a new key_share. The server combines the PSK and the ECDHE output to derive session keys. Even if the PSK is compromised, the ECDHE contribution ensures past traffic remains protected. RFC 8446 recommends PSK-with-DHE for all resumption cases where forward secrecy is required.

TLS 1.2 had over 300 cipher suite combinations, many insecure. TLS 1.3 reduces this to 5 cipher suites, all using AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, and TLS_AES_128_CCM_8_SHA256. Key exchange and authentication are negotiated separately via supported_groups and signature_algorithms extensions. This separation eliminates the combinatorial complexity of TLS 1.2 and ensures every TLS 1.3 connection uses authenticated encryption.

In practice, 0-RTT is most useful for HTTP/2 connections where the client repeats a GET request (safe and idempotent) to a previously visited server. Browsers implement 0-RTT cautiously: Chrome enables it for safe HTTP methods; POST requests are never sent as 0-RTT data. HTTP/3 over QUIC integrates TLS 1.3 natively — QUIC's 0-RTT reuses TLS 1.3's mechanism. In QUIC, 0-RTT also restores transport parameters (flow control, stream limits) from the previous session, further reducing setup overhead beyond just the TLS layer.

TLS 1.3 includes mechanisms to prevent version downgrade attacks. The ServerHello random field contains a sentinel value when TLS 1.3 is negotiated: the last 8 bytes are set to a fixed value (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 for TLS 1.2 fallback). TLS 1.3-capable clients check for this sentinel when the server negotiates TLS 1.2, detecting active downgrade attempts. Additionally, the finished transcript hash covers the entire handshake including version negotiation, so any tampering is detectable. SCSV (Signaling Cipher Suite Values) like TLS_FALLBACK_SCSV provide a separate downgrade signal for older TLS versions.

Deploying TLS 1.3 requires attention to several operational details. Session ticket encryption keys must rotate (typically every 24 hours) and be synchronized across server clusters to allow resumption to any server. Old ticket decryption keys must be retained for the ticket lifetime to avoid spurious handshake failures. OCSP stapling is more important in TLS 1.3 (one fewer round trip to check certificate status). Load balancers must pass through TLS 1.3 ClientHello without modification — some older middleboxes corrupt unknown extensions, requiring compatibility modes.

Why is 0-RTT early data vulnerable to replay attacks in TLS 1.3?

TLS 1.3 achieves 1-RTT full handshakes and 0-RTT resumption via PSK session tickets. Key derivation uses HKDF with a structured schedule producing separate keys for each traffic layer. 0-RTT early data eliminates one round trip but is vulnerable to replay — mitigated by single-use tickets and limiting 0-RTT to idempotent operations. PSK-with-DHE maintains forward secrecy for resumption. TLS 1.3 restricts cipher suites to 5 AEAD options, eliminating legacy insecure combinations. Downgrade prevention uses sentinel values in the server random field.