Early does not mean replay safe
01A request can arrive before the TLS handshake completes; encryption does not stop an attacker replaying its early ciphertext.
Only this connection’s handshake is complete. Replay elsewhere still requires consistent handling.
Source for this drawing: RFC 8470 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Early data
- Application bytes a returning client can send before a new TLS handshake completes (0-RTT), after the server offers early data for future connections through a TLS session ticket.
- Replay
- An attacker sends a captured request flight again without the original client initiating that copy.
- User agent (client)
- A browser or other application that starts an HTTP request.
- Origin server
- The server responsible for the requested resource, possibly reached through a gateway.
- Safe method
- A method whose intended semantics are read-only, such as GET; this does not make every resource free of replay-sensitive side effects.
- TLS handshake
- The exchange that establishes a protected connection; an early-data request starts after the client sends ClientHello, before that handshake completes.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Choose an explicit replay policy before processing early requests.
- Early data can contain all or only part of a request. A server can reject all early data at the TLS layer, delay individual HTTP requests until handshake completion, or reject individual requests with 425. TLS rejection cannot select just one early HTTP request.
- Absent other information, clients MAY send safe methods in early data and MUST NOT send unsafe methods, or methods of unknown safety. A safe method alone does not guarantee a resource has no replay-sensitive side effects.
- Resource-level early-data configuration is RECOMMENDED. Without explicit information, origins MUST reject early data or ensure requests are not processed before TLS handshake completion. Completing one connection does not prove early data has not been replayed on another connection.
- Intermediaries accepting early data MUST implement the 425 retry mechanism. After accepting early data at TLS, a server MUST handle all requests conveyed in it at HTTP, possibly rejecting individual requests with 425; TLS acceptance does not require performing each requested operation.
Fictional GET /catalog: the client sends it early; this direct server buffers it and waits, then processes it after its handshake completes. This illustrates the delay option, not a claim that early data is universally safe or that TLS acceptance and HTTP application processing are the same decision.
Read the RFC section ↗