0-RTT or a full 1-RTT handshake: when is the speed worth the replay risk?

0-RTT or a full 1-RTT handshake: when is the speed worth the replay risk?

What do you give up to send application data in the very first TLS 1.3 flight? Replay protection — and the answer to whether that matters is entirely about your request semantics.

A standard TLS 1.3 handshake (RFC 8446) completes key exchange in one round trip before any application data. 0-RTT (early data) lets a resuming client send data immediately, encrypted under the PSK, saving that round trip. The cost is structural: early data can be captured and replayed by an attacker, because it is sent before the handshake's anti-replay guarantees are established.

The specification is explicit that 0-RTT data must be safe to replay. That means idempotent operations only — a GET that triggers no state change is fine; a POST that charges a card or mutates a record is not.

— Enable 0-RTT only for idempotent, side-effect-free requests.
— Gate non-idempotent methods to full handshakes server-side.
— Pair with single-use tickets and a replay cache to narrow the window.

Further reading: RFC 8446 §2.3 and §8 (the entire anti-replay discussion).

Bottom line: 0-RTT buys one round trip but breaks replay safety; restrict it to idempotent traffic or do not enable it at all.