Summary

  • TLS 1.3 0-RTT can reduce connection latency, but it does not inherently prevent an attacker from replaying accepted early data.
  • A defensible control joins transport acceptance to request semantics, application idempotency, current authorization and the actual side effect.

Imagine a payment service that permits a familiar client to resume a TLS session and send a transfer request as early data. The edge decrypts the request and forwards it before the new handshake finishes. A replay reaches another edge inside the accepted ticket window. Both edges report valid early data; the ledger receives two commands. The transport did what it promised. The application inferred a promise the transport never made.

The saved round trip has a defined cost

RFC 8446 lets a client that resumes with a pre-shared key send 0-RTT application data before completing a new handshake. This can make a repeated connection feel immediate. It is useful for latency-sensitive reads and other operations whose semantics tolerate repetition.

The security boundary is explicit. TLS does not provide inherent replay protection for 0-RTT data. An attacker who records the early flight can replay the ClientHello and its associated data. The server may still authenticate and decrypt those bytes under the resumption context. Cryptographic acceptance therefore proves that the data fits an accepted early-data context; it does not prove unique delivery or unique execution.

That distinction is easy to lose in telemetry. A dashboard can show a valid ticket, accepted early data and a successful application response. None of those fields says whether the same request reached another process, region or retry path. A green TLS event is narrower than an exactly-once business result.

Anti-replay is an operating system, not a checkbox

RFC 8446 describes several ways to reduce replay exposure. A server can issue single-use tickets, record ClientHellos or apply freshness checks to the ticket age and observed arrival time. Each approach creates an operational dependency. Single-use tickets require acceptance state that cannot be lost or inconsistently shared. ClientHello recording needs a bounded, available replay database. Freshness checks rely on clocks, tolerance windows and a decision about how much replay exposure remains acceptable.

The difficulty grows across a distributed edge. If two sites can accept the same resumption material without a common single-use decision, a local “not seen before” result is not global evidence. If failover deliberately permits acceptance while replay state is unavailable, availability policy has widened the execution surface. That may be a reasonable trade, but it must not disappear behind the label 0-RTT accepted.

Nor does rejecting early data remove application responsibility. A client can retry after the handshake. If the first attempt crossed the application boundary before rejection became visible, an automatic retry can still duplicate the side effect. The evidence must follow the request through acceptance, rejection, forwarding and retry—not stop at the TLS record.

HTTP exposes the missing application decision

RFC 8470 defines how HTTP uses early data and makes replay risk visible to clients, intermediaries and origin servers. A client should not casually place an unsafe operation in early data. An intermediary needs to signal that a request arrived early. A server that is unwilling to risk processing the request can answer with 425 Too Early, prompting a retry outside early data.

The status code is a control handoff, not a declaration that accepted requests are harmless. Method names alone are also an incomplete proxy. A nominally safe request can trigger metering, scarce allocation or audit effects; a nominally idempotent write can fail to be idempotent when its application key is missing or scoped differently across regions. Replay safety belongs to the operation as implemented under current state.

QUIC makes the same boundary operationally important. RFC 9001 integrates TLS early data into QUIC, where the server can reject 0-RTT and the client must handle that outcome. The resulting resend path is part of the application execution graph. Counting only accepted QUIC packets cannot establish whether the business command was applied once.

Build an early-data decision receipt

The durable evidence object is an early-data decision receipt. It should bind the resumption ticket fingerprint and age, ClientHello or handshake reference, accepting edge, anti-replay mechanism, replay window, request fingerprint, method and side-effect class, application idempotency key, principal and authorization-policy epoch, forwarding result, retry history, committed effect and decision timestamps.

The receipt must also record uncertainty. A locally unique observation cannot prove fleet-wide uniqueness. A valid ticket cannot prove current business authority. A request hash cannot prove equivalent semantics if hidden headers, account state or regional scope changed. A transport rejection cannot prove that no downstream component observed the first attempt.

This separation makes the performance decision governable. Teams can permit 0-RTT for operations whose repeats are harmless, require a globally enforced idempotency key for bounded writes, or decline early data when authorization and irreversible effects cannot be decided safely. The useful metric is not the percentage of handshakes accelerated. It is the percentage of early-data operations whose execution history remains explainable.

Sources