Summary

  • QUIC 0-RTT acceptance is a TLS and transport decision, not proof of one-time application execution.
  • A packet ACK confirms transport processing; it does not establish replay safety, durable commit, client identity, or business success.
  • The application must define acceptable early-data use and preserve separate evidence for execution, idempotency, side effects, and outcome.

QUIC 0-RTT begins with a useful but narrow promise. A client reuses configuration associated with a previous connection, including a TLS session ticket, to send application data before the new handshake completes. The server signals acceptance by including the TLS early_data extension in EncryptedExtensions. It then processes and acknowledges received 0-RTT packets. If the extension is omitted, 0-RTT is rejected and those packets must not be processed as accepted early data.

That sequence is important evidence, but it stops at the transport and cryptographic boundary. Acceptance does not prove that an application handler ran exactly once. An acknowledgment does not prove that the request reached a downstream service, crossed a durable commit boundary, or produced a customer or financial result. Nor does it prove client liveness or authenticated client identity before the handshake has completed. Address validation may provide additional evidence, but it does not turn a replayable request into a unique business action.

The reason is inherited from TLS early data: replay remains possible. TLS mitigations reduce exposure but are not a universal application guarantee. QUIC's core transport processing is designed to be idempotent, so replaying transport frames does not by itself create invalid connection state. The risk appears in the application information carried by those frames. STREAM, RESET_STREAM, STOP_SENDING and CONNECTION_CLOSE can all carry application meaning and can therefore be unsafe in 0-RTT.

A QUIC application protocol must define an acceptable-use profile; a client should send application data in 0-RTT only when that profile specifically permits it.

HTTP illustrates the boundary without removing it. In early data, clients should use safe methods when better information is absent and must not use unsafe or unknown-safety methods. HTTP Early-Data can communicate that an intermediary forwarded a request under early-data conditions. A 425 Too Early response means the server is unwilling to risk processing a request that might be replayed. The retry must not itself use early data. Waiting for the handshake after an intermediary has marked a request Early-Data does not retroactively make that request safe, and distributed instances need consistent treatment.

An evidence ledger should not compress this chain into one “success” flag. Record the session ticket and remembered configuration; whether 0-RTT was attempted, accepted, or rejected; packet acknowledgment; Early-Data propagation and 425 handling; request identity and any idempotency key; application execution attempts; side effects; durable commit receipt; retry or replay observations; and customer or financial outcome. Idempotency keys, transaction journals, distributed replay ledgers, and business receipts are operational recommendations derived from this proof boundary, not QUIC requirements unless an application protocol specifies them.

The practical conclusion is selective use, not universal disablement. Disabling 0-RTT is the strongest replay defense, but bounded, replay-tolerant operations may still justify it. The claim must remain proportionate: accepted early data is evidence of an early-data decision, not a transaction commit.