A resumed TLS 1.3 connection can carry application bytes before the server finishes the new handshake. That latency reduction changes a security boundary: early data is protected in transit, yet the protocol does not give it the same replay property as ordinary post-handshake application data.

The distinction matters when an endpoint maps one request to a state-changing operation. A captured early-data flight can be presented again under conditions in which a server accepts it, so confidentiality and integrity on the wire do not imply single execution.

Early traffic keys come from resumption state

After a successful TLS 1.3 connection, a server can issue a NewSessionTicket. The client later uses the associated PSK in a resumed handshake. If the ticket permits early data, the client can derive early traffic keys and transmit 0-RTT bytes with its first flight.

prior connection
    │
    └── NewSessionTicket + PSK state
                │
                ▼
resumed connection
ClientHello + early data ──────────► server
                         ◄────────── ServerHello ... Finished
client Finished ───────────────────►
post-handshake application data

The server can reject early data while still continuing the handshake. Acceptance is therefore separate from successful resumption. Applications also need behavior for rejected early data; retrying it after the handshake can be valid only when the operation’s semantics permit a retry.

Encryption does not provide single execution

TLS authenticates encrypted records, but a valid early-data sequence can be replayed as a sequence. The attacker does not need to decrypt or modify the request to cause a second presentation.

Consider an HTTP request whose authenticated session and application policy allow a mutation:

POST /api/credits/transfer HTTP/1.1
Host: service.example
Content-Type: application/json

{"destination":"account-b","amount":25}

Sending such an operation in early data is unsafe unless the application has an independent mechanism that makes duplicate execution harmless or detectable. The transport can verify that the bytes correspond to valid early traffic; it cannot infer whether a second transfer is semantically equivalent to a harmless duplicate.

This is also distinct from packet duplication inside one connection. TLS record processing has sequence state for a connection. The 0-RTT replay concern crosses connection attempts and resumption contexts.

Server replay controls have deployment boundaries

TLS 1.3 permits servers to implement anti-replay measures, but those measures carry state and topology assumptions. A server can record recently used resumption information and reject reuse. In a distributed service, that decision may require shared state or routing that keeps related resumptions within one replay-control domain.

A cluster with independent replay caches illustrates the boundary:

             ┌── edge A ── replay cache A
client ──────┤
             └── edge B ── replay cache B

first presentation  → edge A records it
second presentation → edge B has no matching record

The exact result depends on the ticket design, key distribution, routing, and anti-replay implementation. TLS does not make independently operated front ends share replay state automatically.

Ticket lifetime is not a replay guarantee either. A short lifetime narrows the period in which resumption material is accepted, but it does not by itself enforce one-time use inside that period.

Application semantics remain the final gate

A robust deployment treats 0-RTT eligibility as an application decision rather than a blanket TLS optimization. Operations that are safe to repeat are easier candidates. Operations with external side effects, authorization transitions, counters, purchases, message submission, or irreversible mutations need stronger treatment.

An application can use an idempotency key for selected operations:

Idempotency-Key: 7c3d...unique-value
        │
        ▼
server-side operation record
        │
        ├── unseen → execute and record result
        └── seen   → return recorded result

That mechanism has its own requirements. The key must be bound to the relevant authenticated principal and operation, retained for an appropriate interval, and processed atomically with the state change. A client-supplied identifier without server-side uniqueness enforcement is not replay protection.

Another policy is simpler: accept early data only for request classes that the application explicitly marks as replay-tolerant, and defer all other application data until the handshake completes. HTTP method names can inform that policy, but method classification alone is insufficient when an endpoint violates the expected semantics or a nominally safe request triggers a side effect.

Authentication context can change across the boundary

Early data is sent before the fresh handshake completes. Its security context is tied to the resumption PSK and the original connection rather than to all properties that may become available later in the new handshake.

A deployment that relies on fresh client authentication, newly evaluated authorization state, or connection-specific policy cannot assume those checks already apply to 0-RTT bytes. The application and TLS termination layer must agree on which requests can cross that boundary and which identity attributes are valid at that point.

This becomes especially important when TLS terminates at a reverse proxy. If the proxy forwards early requests to an origin, the origin needs a trustworthy signal or an enforced proxy policy; otherwise the component making the state-changing decision may not know that the request arrived as replayable early data.

Latency policy and security policy must share the same boundary

0-RTT removes waiting from a narrow part of connection establishment. It does not convert replay-sensitive operations into replay-safe ones. The useful deployment boundary is therefore explicit: resumption can be broadly enabled while early-data acceptance remains restricted by request semantics, replay-control scope, and current authentication requirements.

Where a service cannot maintain suitable replay state or cannot classify an operation as safe under duplicate presentation, rejecting early data for that operation preserves the stronger execution assumptions of post-handshake traffic. The latency gain remains available only where the application can absorb the weaker replay property without changing security outcomes.

TLS 1.3 0-RTT Replay Transport Security