<b>What actually makes TLS 1.3 0-RTT early data replayable, and why can't the protocol simply forbid it?</b>

<b>What actually makes TLS 1.3 0-RTT early data replayable, and why can't the protocol simply forbid it?</b>

Zero round-trip time (0-RTT) lets a client send application data in its first flight, encrypted under a key derived from a resumption PSK before the server has responded. The latency win is real; the security cost is precise.

The replay problem is structural, not a bug. Early data is protected by a key derived solely from the PSK and the ClientHello — there is no server-contributed randomness mixed in yet (the server's Diffie-Hellman share only protects later data). An attacker who captures the ClientHello plus early-data records can resend the identical bytes to the same or a different server in a cluster. RFC 8446 §8 is explicit: the protocol does not guarantee non-replay for 0-RTT.

Mitigations are defenses, not proofs. RFC 8446 describes two: single-use tickets (server records each ticket and rejects reuse) and a ClientHello recording window keyed by the obfuscated_ticket_age and freshness bounds. Neither is airtight across a distributed front-end where state isn't shared.

The operational rule that follows: only idempotent requests belong in early data. GET, yes; a POST that charges a card, no. Cloudflare and others gate 0-RTT to safe methods for this reason.

Further reading: RFC 8446 §8, §2.3; Fastly's 0-RTT engineering notes.

Bottom line: 0-RTT replay is inherent to sending data before the server adds entropy — treat early data as at-least-once delivery.