TLS 1.3 Early Data Trades a Round Trip for Replay Exposure

A returning TLS 1.3 client can possess a resumption ticket and application data ready to send before a new handshake has finished. Early data, commonly called 0-RTT data, permits those bytes to travel in the client’s first flight. The latency benefit changes a security property at exactly the point where an application may be tempted to act: early data does not carry the same replay protection as ordinary post-handshake application data.

The distinction is not a defect in TLS authentication. It follows from the timing of 0-RTT. A server can process early application bytes before the fresh handshake establishes the connection state that later traffic receives. TLS 1.3 therefore requires applications using early data to account for replay, rather than treating every successfully decrypted early request as a unique event.

Resumption state authorizes an early flight

TLS 1.3 early data depends on a pre-shared key. A common source is a NewSessionTicket issued after an earlier connection. The ticket lets a later connection attempt PSK resumption, and the server can advertise a max_early_data_size value that permits the client to send a bounded amount of application data before handshake completion.

Acceptance is constrained by parameters associated with the selected PSK. TLS 1.3 requires the server to match relevant properties including the protocol version, cipher suite, and negotiated ALPN value when applicable. A server can reject early data while still continuing the connection through a normal handshake. Acceptance is also coarse at the TLS layer: the server does not accept selected early records while rejecting others as a TLS decision.

This creates an important separation. TLS decides whether the early-data flight is accepted cryptographically. The application still decides whether acting on a particular request before handshake completion is acceptable.

Successful decryption does not establish uniqueness

An attacker that records valid early data can attempt to present a copy on another connection. The attacker does not need to forge the protected request. The security issue is reuse of bytes that were already valid under resumption state.

TLS 1.3 specifies anti-replay strategies for servers, but deployment architecture makes perfect global replay rejection difficult. A service may have many front ends, ticket keys may be shared, and replay state may need coordination across failure domains. The protocol text explicitly treats 0-RTT as having weaker replay properties than later application data.

That boundary matters most when a request produces an externally visible effect. A duplicated account mutation, reservation, message submission, or financial instruction can be harmful even if both copies were confidential and authenticated in the cryptographic sense applicable to early data. Encryption protects the request from unauthorized modification; it does not by itself turn a replayable operation into an exactly-once operation.

HTTP carries replay context across proxy hops

HTTP deployments often terminate TLS before the origin application. A reverse proxy may receive a request in early data and then forward it over a different connection. If replay context disappears at that boundary, the origin can mistake a request exposed to 0-RTT replay for ordinary post-handshake traffic.

RFC 8470 defines the Early-Data request field for this case. An intermediary that forwards a request before its client-side TLS handshake completes marks the forwarded request with Early-Data: 1. The marker represents replay exposure on a previous hop; waiting for a later origin-side handshake to finish cannot erase that earlier property.

The same RFC defines status code 425 Too Early. An origin can use it when processing a request would carry unacceptable replay consequences. A client retry triggered by 425 is sent without early data. This gives an origin a protocol mechanism to reject replay-sensitive work without requiring every intermediary to infer application semantics.

HTTP method labels are useful but not sufficient policy

Safe HTTP methods provide a useful default signal because they are specified as read-only in their intended semantics. RFC 8470 permits clients, absent better information, to send requests with safe methods in early data and prohibits sending methods whose safety is absent or unknown.

Method classification is still not a complete application policy. A nominally safe request can trigger effects in a poorly designed service, while an application may have explicit replay controls for a narrowly defined operation. The relevant property is the consequence of duplicate processing, not merely the spelling of the method token.

Idempotence is related but also distinct. An idempotent operation is specified so multiple identical requests have the same intended effect as one, but implementation details can still produce secondary effects such as duplicate audit events, repeated downstream calls, or rate-limit consumption. Replay tolerance has to cover the actual processing path that starts before the handshake completes.

Distributed termination widens the replay decision

A single TLS endpoint can keep local replay state more easily than a fleet spread across regions. Once session ticket material is accepted by multiple nodes, anti-replay state becomes a distributed systems problem. A design that rejects a ticket’s early data after first use on one node gains little if another eligible node has no timely record of that use.

TLS 1.3 describes deployment strategies with different trade-offs, including limiting ticket validity and arranging shared replay state. None converts early data into ordinary application data with identical security properties. Services that cannot make replay-sensitive operations safe can simply reject 0-RTT while retaining TLS 1.3 and session resumption.

Consistency across gateways also matters. If one edge delays a sensitive request until handshake completion while another processes the same class immediately, routing can alter the replay outcome. RFC 8470 requires consistent handling where different server instances could otherwise make conflicting decisions about early data.

The performance boundary belongs near operation semantics

The useful optimization is not “enable 0-RTT everywhere.” It is allowing early execution only where duplicate processing has acceptable consequences or where a stronger application mechanism absorbs the replay risk. Static retrieval is a common fit. State-changing operations usually require more scrutiny, especially when they cross into payment, messaging, provisioning, or other systems that cannot cheaply reverse duplicate effects.

Application-level idempotency keys can narrow some risks when their uniqueness scope, retention period, atomicity, and downstream propagation are designed for the operation. They are not a generic substitute for early-data policy. A key checked after an irreversible side effect, stored only on one node, or expired before the replay window closes does not provide the intended boundary.

Rejecting early data for sensitive routes is often simpler. The handshake then completes before application processing begins, restoring the stronger connection properties expected by ordinary request handling. The cost is the round trip that 0-RTT was designed to remove.

TLS 1.3 early data is therefore a latency feature with an application-visible security contract. Its safe deployment depends on preserving replay context through intermediaries and placing the final acceptance decision where the consequences of duplicate execution are actually known.