Summary

  • QUIC handshake completion is evaluated from each endpoint’s own perspective and does not happen simultaneously everywhere.
  • HANDSHAKE_DONE, or the qualifying 1-RTT ACK alternative at the client, confirms a protocol state transition and permits Handshake-key discard.
  • Confirmation must be joined with 0-RTT and application evidence before a service is labelled ready.

The operational trap is easy to understand. A readiness dashboard receives HANDSHAKE_DONE and turns green. At the same time, the server may have rejected early data, while the client is required to reset the streams and application state associated with that data. The green signal is real, but its meaning is narrower than the dashboard label suggests.

RFC 9001 defines completion locally. A TLS handshake is complete when a local TLS stack has sent a Finished message and verified the peer’s Finished message. That condition is not a simultaneous event at both endpoints. A server therefore evaluates completion from its own evidence, and a client does the same from its own perspective.

The confirmation rules then differ by role. When the handshake completes at the server, the server is confirmed and must send HANDSHAKE_DONE as soon as the handshake completes. At the client, receipt of HANDSHAKE_DONE confirms the handshake. The client may also infer confirmation from an acknowledgment covering a packet it sent with 1-RTT keys. RFC 9000 permits only a server to send HANDSHAKE_DONE; the frame tells the client that the server received and processed the client’s Handshake packet. It is connection-state signalling, not an application reply.

The practical consequence is a precise key-lifecycle boundary. Once confirmation occurs, the endpoint must discard Handshake keys. This retires the Handshake cryptographic epoch. It does not show that an application protocol completed its own negotiation, that a request reached application code, that a dependency is healthy, or that a business workflow committed its result.

Initial-key disposal is a different event. The client discards Initial keys when it first sends a Handshake packet. The server does so when it first successfully processes a Handshake packet. Those actions occur on different evidence and must not be merged with confirmation or Handshake-key retirement. A trace that records one disposal event as if it represented the whole establishment sequence loses the distinctions that operators need.

0-RTT creates another boundary. A server accepts 0-RTT by including the early_data extension in EncryptedExtensions and rejects it by omitting that extension. If it is rejected, the server must not process 0-RTT packets, and the client must reset all streams, including application state bound to those streams. A later HANDSHAKE_DONE cannot turn rejected early data into accepted work.

Replay is also an application-protocol responsibility. RFC 9001 warns that 0-RTT application data can be processed multiple times because of replay. A client must not use 0-RTT for application data unless the application specifically requests it, and the application protocol must define acceptable use. Handshake confirmation therefore cannot prove replay safety, exactly-once execution, durable commit, or acceptance of the early request.

The right interpretation of a qualifying 1-RTT ACK is equally limited. It establishes the confirmation condition defined by RFC 9001 when it covers the client’s lowest 1-RTT packet number. It does not expand an ACK into evidence of application consumption, durable storage, authorization, or business completion. Confirmation is best treated as a cryptographic-state receipt: valuable, precise, and incomplete.