---
title: "What TLS 1.3 Early Data Changes Before the Handshake Completes"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/tls13-resumption-early-data-replay-scope"
last-updated: "2026-10-20"
---

# What TLS 1.3 Early Data Changes Before the Handshake Completes

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

TLS 1.3 early data can move an application request ahead of the new server response, changing the point at which processing may begin. Evaluate that earlier start alongside replay exposure and the operation's consequences. A resumed connection, encrypted request and completed handshake do not together establish exactly-once application effects.

## Resumption does not establish that early data was used

RFC 8446, published in August 2018, describes resumption as establishing a new connection using a pre-shared key, or PSK, derived from an earlier handshake. Optional early data adds encrypted application bytes to the client's first flight, before a new server response. Resumption can occur without it.

For an offer promising faster resumed sessions, identify which of those two behaviors the evidence actually covers. A record saying resumed leaves the early-data question unanswered. Equally, a feature's availability does not show that the offered application sends or processes requests that way.

The 0-RTT label concerns a TLS setup wait. Sending earlier still leaves travel to the receiving endpoint, request handling and a response to account for. A buyer comparing inference services needs the completed workload's timing; the label supplies no zero-delay or zero-inference-time result.

References: [T1](https://www.rfc-editor.org/rfc/rfc8446.txt), [T3](https://www.rfc-editor.org/rfc/rfc9325.html#section-3.10)

## The first-flight keys have a different security boundary

Early-data encryption uses keys derived from the offered PSK, without a fresh server contribution. RFC 8446 therefore gives early data neither forward secrecy nor an inherent guarantee against replay across connections. Later exposure of that PSK can compromise the confidentiality of recorded early data. Adding fresh Diffie-Hellman exchange to the resumed handshake can provide forward secrecy for subsequent traffic without retroactively changing the early bytes.

The RFC separately protects against duplication of the same early data within one connection. Section 8 also requires each server instance to accept a given 0-RTT handshake at most once; stronger protections are discussed there. That limited boundary is different from application-wide uniqueness.

For a confidentiality requirement extending beyond the exchange itself, the buyer's question is which data received which protection. For a one-operation requirement, the question is which effects could result from repeated processing. An encryption statement cannot answer both.

References: [T1](https://www.rfc-editor.org/rfc/rfc8446.txt)

## Compare an immutable read with a resource creation

Consider an invented application with two operations. Read R retrieves a fixed public document D. Stipulate that R never changes D and never creates a reservation or job. Create C instead adds one new job record on every successful processing, with no duplicate suppression.

Now compare one successful processing with two successful processings of the same logical request. For R, D remains unchanged in either case, but two processings can consume processor time, response bandwidth and logging storage twice. For C, the stipulated record count changes from one to two. One intended job now has two records.

The useful distinction is what repeating the processing would mean. R preserves the named document while still consuming resources. C violates a requirement for one job under the stipulated contract. Neither description establishes that either operation is appropriate for early data in a real application.

HTTP's safe-method definition does not promise an absence of incidental effects. RFC 9110, published in June 2022, explicitly allows behavior such as request logging. A GET label alone cannot substitute for evidence about the actual resource and processing.

If an offer relies on an application key to suppress duplicates, use the related API idempotency guide for its operation, parameter, geographic and recognition-period rules. Those are additional application promises; this example establishes none of them.

References: [H1](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.1)

## A later hop can carry an earlier exposure

RFC 8470, published in September 2018, defines the Early-Data request header with value 1 to carry early-data context through intermediaries. An intermediary forwarding before its client-side handshake completes must include it and must preserve an existing field.

Consider a separate fictional path from client A through terminating gateway G to origin O. Stipulate that G forwards A's early request before the A-G handshake completes, using an already established G-O connection. O receives it over that established connection, but the completed G-O handshake does not erase the earlier A-G replay exposure.

A proposal showing only the G-O handshake would leave the buyer unable to locate when G began acting on A's request. Ask the evidence owner to identify that event and how the origin receives its context.

RFC 8470 also addresses requests only partly carried in early data: what matters is when a server begins acting on their contents. Finishing delivery later is not proof that earlier processing was deferred.

References: [T2](https://www.rfc-editor.org/rfc/rfc8470.html)

## 425 Too Early is a decision about processing risk

RFC 8470 defines 425 Too Early as the server's unwillingness to risk processing a request that might be replayed. At the protocol level, RFC 8470 requires a client that sent the request in early data to retry after 425; it recommends automatic retry for user agents and requires the retry to be outside early data. This is HTTP-level handling, distinct from TLS rejecting early data.

For a buyer, a 425 outcome needs to be explained alongside the claimed latency result. It does not establish that another instance performed no earlier work. A successful later response likewise leaves any prior effects to be accounted for. Neither status alone reconciles the application's resource records.

References: [T2](https://www.rfc-editor.org/rfc/rfc8470.html)

## Judge the latency claim against the operation being purchased

RFC 9325, the November 2022 TLS security recommendations, treats early data as a latency and security tradeoff requiring attention above the TLS library. It points HTTP readers to RFC 8470 and requires an explicit application-protocol specification to define appropriate, secure use for other protocols.

Use that applicability boundary when comparing offers. Ask which application operation the claim covers, whether the evidence concerns resumption alone or accepted early data, and which component begins processing at the reported milestone. Then connect that milestone to the result the application actually needs.

For the fictional read, an earlier send might be relevant to retrieving D, while the report still owes the buyer a completed-response measurement and an account of repeated work. For the fictional creation, a faster first send leaves the one-job requirement unresolved until the application contract and effects are explained. These are different purchase consequences even if the transport label is identical.

Keep ownership of adjacent questions clear. The related MACsec/TLS guide locates encryption endpoints; the HTTP/2 guide distinguishes transport streams from model execution. This article evaluates the earlier processing opportunity and its replay boundary.

References: [T3](https://www.rfc-editor.org/rfc/rfc9325.html#section-3.10)

## Carry a separate cabling requirement into the physical scope

If the selected network equipment also needs physical connections, Leviathan's Structured Cabling & Fiber Installation service can discuss agreed routes, endpoint labels and connection records using customer-furnished or separately sourced materials. Use the related service and project inquiry with a nonconfidential outline of the equipment, endpoints and required handoff.

TLS behavior and application-effect acceptance remain with the appointed network, application and security owners. The physical cabling package records the agreed installation.

References: [L1](https://www.leviathansystems.co/services/structured-cabling)

## Primary sources

- [T1 — RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446.txt). Checked 2026-10-20. August 2018; sections 2.2–2.3 and 8 distinguish PSK resumption, optional early data and replay boundaries. Forward-secrecy statements apply separately to early and subsequent traffic.
- [T2 — RFC 8470 — Using Early Data in HTTP](https://www.rfc-editor.org/rfc/rfc8470.html). Checked 2026-10-20. September 2018; sections 2–5.2 explain processing timing, intermediary context, 425 Too Early and its retry semantics. These HTTP semantics do not establish a particular product's behavior.
- [T3 — RFC 9325 — Recommendations for Secure Use of TLS and DTLS, section 3.10](https://www.rfc-editor.org/rfc/rfc9325.html#section-3.10). Checked 2026-10-20. November 2022; explains the early-data tradeoff and the need for an applicable protocol specification, directing HTTP to RFC 8470.
- [H1 — RFC 9110 — HTTP Semantics, section 9.2.1: Safe Methods](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.1). Checked 2026-10-20. June 2022; distinguishes safe-method semantics from incidental implementation effects. The read and creation contracts in this article are expressly invented.
- [L1 — Leviathan Systems — Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Physical fiber and copper installation to agreed routes, endpoint labels and connection records; materials and included verification are project-specific.

## Related Leviathan resources

- [Locate MACsec frame protection and TLS channel endpoints](/articles/macsec-frame-protection-tls-channel-endpoints)
- [Read the application scope of an API idempotency key](/articles/api-idempotency-key-scope-request-effects)
- [Separate HTTP/2 streams from inference batches and workers](/articles/http2-concurrent-streams-versus-inference-batches)
- [Structured Cabling & Fiber Installation](/services/structured-cabling)
- [Discuss equipment endpoints and the physical cabling handoff](/contact?service=structured-cabling&from=%2Farticles%2Ftls13-resumption-early-data-replay-scope)

## Define the physical connections for the selected equipment

Share a nonconfidential equipment, endpoint, route and connection-record outline to discuss cabling scope, requirements and availability.

[Discuss the scope](/contact?service=structured-cabling&from=/articles/tls13-resumption-early-data-replay-scope)