TLS 1.3 Early Data Trades a Round Trip for Replay Exposure

A resumed TLS 1.3 connection can carry application bytes before the server has completed the new handshake. That latency reduction is attractive on paths where a round trip is expensive, but it changes a security property that applications often assume without naming it: a protected request is not necessarily fresh merely because the server decrypted it successfully.

TLS 1.3 calls this facility early data, commonly described as 0-RTT. It is available when the client and server share a pre-shared key, including one established through a prior connection. The client can derive keys and send application data in its first flight rather than waiting for the server’s handshake messages.

The encryption remains meaningful. A passive observer does not receive plaintext merely because the data arrived early. The sharper issue is replay across connections. TLS 1.3 does not give 0-RTT data the same replay guarantees as ordinary application data sent after the handshake. That difference pushes part of the security decision above TLS, into the semantics of the request itself.

Early data is tied to a previous security context

A client cannot send arbitrary 0-RTT data on a first encounter with an unrelated server. Early data depends on a PSK that both sides already possess. In a common resumption flow, the server issued a session ticket during an earlier connection, and the client presents the associated PSK identity when reconnecting.

The early-data parameters are also constrained by the security context associated with that PSK. TLS 1.3 requires the selected protocol version, cipher suite, and negotiated application protocol to remain compatible with the stored context before the server accepts early data. These checks prevent a client from carrying early bytes into a materially incompatible negotiated context.

They do not establish freshness. The client sends the first application records before receiving the new ServerHello, so those records cannot depend on fresh server contribution from the current connection. RFC 8446 consequently states that 0-RTT data has weaker security properties: it is not forward secret and it has no inherent guarantee against replay between connections.

That distinction is easy to hide behind a generic “TLS protected” label. For application design, the relevant question is not only whether traffic is encrypted and authenticated. It is also whether processing the same authenticated request more than once can cause a security or correctness failure.

Replay risk follows application semantics

A duplicated request is harmless only when duplicate processing is harmless under the application’s actual rules. A read that returns a public representation may tolerate replay. A request that transfers funds, consumes a one-time capability, submits an order, changes account state, or triggers an external action has a very different replay profile.

HTTP already has a vocabulary for part of this distinction. Safe methods are defined as methods whose requested semantics are essentially read-only. RFC 8470 uses that property when specifying HTTP use of early data: absent stronger information, clients may send requests with safe methods in early data and must not send unsafe methods, or methods with unknown safety, that way.

Method classification is only a starting point. An endpoint can violate the intended semantics of an HTTP method, and apparently read-only work can still consume scarce resources or interact with application state. Conversely, an application may have a carefully designed idempotency mechanism for a mutation. The transport layer cannot infer those properties from encrypted bytes.

This is the central operational boundary. TLS can identify data as early and servers can control whether to accept it, but only the application has enough context to judge whether replay is acceptable for a particular operation.

Anti-replay state becomes a distributed-systems problem

TLS 1.3 describes mechanisms that servers can use to limit replay exposure, including recording information associated with accepted ClientHello messages or using ticket-age checks within a bounded acceptance window. These mechanisms can reduce risk, but they introduce state, coordination, availability, or deployment constraints.

A single process with local anti-replay state is the simple case. Real services often terminate TLS across many processes, hosts, regions, or edge locations. A replay defense that is effective only within one instance can fail when another instance accepts the same early data independently.

Global coordination can tighten the boundary, but it is not free. Shared replay state adds synchronization and availability concerns to a path that was adopted partly to reduce latency. Partitioned state can preserve local performance while leaving cross-partition replay opportunities. Short ticket lifetimes and narrow acceptance windows reduce exposure without eliminating the architectural tension.

TLS 1.3 explicitly accounts for distributed deployments in its anti-replay discussion. The protocol does not turn 0-RTT into a universal low-latency mode with ordinary 1-RTT semantics. Operators have to decide whether the latency gain justifies the replay controls required by their application and topology.

HTTP carries replay context across intermediaries

A reverse proxy or gateway complicates the boundary because the component terminating TLS may not be the component that knows whether an HTTP operation is safe to process early. RFC 8470 addresses this split with the Early-Data request header and the 425 Too Early response status.

An intermediary that forwards a request before its client-side handshake has completed marks the forwarded request with Early-Data: 1. The signal preserves replay context after the request leaves the TLS connection on which early data arrived. An origin that cannot safely process such a request can return 425 Too Early, causing a capable client to retry after the handshake rather than repeating the request in early data.

The header is not a claim that a request is malicious. It says the request may carry early-data replay exposure. That is enough for an origin to apply endpoint-specific policy.

The distinction matters when several proxy layers are present. A gateway must not erase the signal merely because its own upstream connection completed normally. The replay condition arose on an earlier hop and survives that transport transition. RFC 8470 therefore requires intermediaries to preserve the header when it is present.

A server also cannot neutralize a forwarded Early-Data: 1 request simply by waiting for its current TLS handshake to finish. The potentially replayed event already occurred on a previous hop. If the operation cannot tolerate that condition, rejection and a non-early retry are the appropriate boundary.

TLS acceptance is coarser than HTTP policy

At the TLS layer, a server accepts or rejects early data for the connection; it cannot selectively accept individual early-data records based on the HTTP operation they contain. Once HTTP is visible, a server or gateway can make finer decisions about particular requests.

This difference creates a useful separation of responsibilities. A TLS terminator can disable early data entirely for a service whose traffic has little replay tolerance. Where mixed traffic makes 0-RTT valuable, HTTP-aware infrastructure can delay sensitive requests until the handshake completes or reject them with status 425 while permitting operations whose semantics tolerate replay.

Care is required around partial deployment. If one edge location forwards early requests while another delays them, or one origin instance interprets the replay signal while another ignores it, the effective policy becomes dependent on routing. RFC 8470 calls for consistent handling across server instances when different decisions could cause unsafe processing.

The same concern applies during configuration rollout. Enabling early data at a CDN or load balancer is not solely a TLS tuning change. It can alter the request conditions seen by every state-changing endpoint behind that terminator. Application owners and transport operators therefore share the policy boundary.

Retry behavior can duplicate effects without an attacker

Replay analysis should not focus only on an adversary copying packets. Network clients already retry requests after connection failures, timeouts, and ambiguous responses. A server can complete an operation while the response is lost, leaving the client unable to tell whether retrying will repeat the effect.

Early data adds another route to duplicate delivery. A server may reject 0-RTT at the TLS layer, after which the client application can choose to retransmit data once the handshake completes. TLS 1.3 advises against automatic retransmission by the TLS implementation because the application is better placed to decide whether resending is valid.

This reinforces a broader design point: idempotency and deduplication remain application properties. An idempotency key backed by durable application state can protect a particular operation from duplicate execution, but it must be scoped and retained according to the operation’s semantics. TLS anti-replay machinery does not replace that application control, and application deduplication does not change the weaker cryptographic properties of 0-RTT.

The two layers address different forms of risk. Transport anti-replay mechanisms limit acceptance of duplicated early flights. Application controls limit duplicate effects when equivalent operations arrive through retries, replays, or other delivery paths.

Latency policy belongs beside replay policy

The most defensible 0-RTT deployments treat early data as a separate request condition rather than a transparent acceleration switch. The service has to know which operations can tolerate replay, which components terminate TLS, where replay context is preserved, and whether all instances apply compatible decisions.

For some services, disabling early data is the cleanest result. A single avoided round trip has little value if nearly every meaningful request must be delayed or retried. Other services have a large set of replay-tolerant reads and can gain latency without extending early processing to sensitive mutations.

The boundary should remain explicit as architecture changes. New endpoints, additional gateways, regional expansion, ticket-sharing changes, and altered retry behavior can all change the replay surface even when the TLS configuration itself appears unchanged.

TLS 1.3 early data is therefore best treated as an application-aware transport feature. Its performance benefit arrives before the new handshake finishes; its security cost arrives in the form of weaker freshness guarantees. Keeping those two properties together prevents a latency optimization from silently becoming an authorization or transaction-integrity assumption.