QUIC with TLS 1.3 lets a resuming client send application data in its very first flight, known as 0-RTT. What does that buy, and what must a server do about replay?

## The handshake economics A fresh QUIC connection completes the TLS 1.3 handshake in one round trip, then carries the request — 1-RTT to first byte of request. Compare with TCP + TLS 1.3, which needs a TCP handshake and then a TLS handshake before that. Resumption improves it further. When a client has connected before, the server may have issued a **session ticket** (a NewSessionTicket message) containing or referencing a pre-shared key (PSK). On the next connection the client can derive an *early data* key from that PSK and attach application data to the very first packet it sends. The server, on recognizing the ticket, can decrypt and process it before the handshake finishes. That is **0-RTT**: the request is on the wire at time zero. What you save is one full round trip on every resumed connection. On a 30 ms intra-region path that is minor; on a 150 ms mobile path where connections are re-established constantly as the radio sleeps, it is a visible product improvement. ## Why early data is dangerous Two distinct weaknesses: **1. No forward secrecy.** 1-RTT keys come from a fresh ephemeral key exchange for this connection. Early-data keys come from the stored resumption secret. If that secret is later compromised — a stolen ticket key, a compromised server — recorded early data can be decrypted. Everything after the handshake completes is forward-secret as usual. **2. No replay protection.** This is the serious one. The server has no way to know whether the first flight is live traffic or a recording. Anything within the client's first flight can be captured by a network attacker and re-sent, possibly many times and to different servers in the same cluster. The server will decrypt it, see a valid request, and execute it. If the request was `POST /transfer?amount=100`, that transfer happens again. A subtler variant: an attacker replays a request repeatedly to force cache pollution, to amplify load, or to observe timing differences. TLS 1.3 explicitly declines to solve this at the protocol level and pushes the responsibility to the application. ## What servers must do **Restrict by method and semantics.** The core rule from RFC 8470 ("Using Early Data in HTTP"): only requests that are **safe** and whose repetition is harmless should be processed from early data — in practice GET and HEAD of resources without side effects. Note that "safe method" is not automatically enough: a GET that increments a counter, sends an email, or triggers an expensive uncached computation is a bad early-data candidate. **Reject the rest with 425 Too Early.** The server answers 425, which tells the client: I will not process this yet, retry it after the handshake completes. Well-behaved clients retry automatically on the same connection once 1-RTT keys are available. This gives you a clean policy: allow-list what is replay-safe, 425 everything else. **Signal across hops.** When a TLS-terminating proxy forwards a request that arrived in early data, it adds the `Early-Data: 1` header field so the origin can apply its own policy and can itself answer 425. An origin must never treat the absence of that field as proof the request was not early data unless it controls the proxy. **Bound replay windows.** Servers should use single-use tickets where possible and keep an anti-replay cache of ticket identifiers with a short ticket lifetime. The hard part is clusters: an anti-replay cache on node A does not stop a replay landing on node B. Shared state (a fast replicated cache) or routing tickets back to their issuing node helps; otherwise treat 0-RTT as replayable across your whole fleet and rely on the application-level policy. **Disable it where the risk is not worth it.** For an API where most requests are mutating, 0-RTT buys little and costs review effort. Turning it off is a legitimate engineering decision. ## QUIC-specific extras - **Anti-amplification.** Before validating the client's address, a QUIC server must not send more than three times the bytes it received. This blunts using 0-RTT as a reflection/amplification vector, and it means large early responses may be paced until address validation completes. - **Address validation with Retry.** A server under load can respond with a Retry packet containing a token, forcing the client to prove it can receive at its claimed address before state is committed. - **Transport parameters are remembered.** A 0-RTT connection reuses remembered transport parameters (flow-control limits, stream counts) from the prior connection; the server must not reduce them below what the client assumed until the handshake confirms new values. - **Rejection is normal.** A server may refuse early data entirely; the client then re-sends that data after the handshake. Clients must therefore be able to buffer and resend, which is why 0-RTT requests must be replayable *by the client* as well. ## The interview-ready summary 0-RTT trades a round trip for two security properties: forward secrecy of the early data and freshness. The mitigation is not cryptographic, it is a policy: allow only requests whose repetition is harmless, answer everything else with 425 Too Early, propagate `Early-Data: 1` across hops, and remember that per-node replay caches do not protect a cluster.