Summary

  • A valid Retry Integrity Tag shows that the sender observed the client’s Initial and that the checked Retry bytes were not accidentally corrupted.
  • It does not authenticate the named server, prove that the token will be accepted, or show that the server has already validated the client address.
  • Incident evidence should keep tag validation, token return, server token validation and the authenticated TLS result as distinct events.

A packet trace shows a QUIC Retry with a valid integrity tag. The dashboard labels it an “authenticated server challenge” and marks the client address as validated. Both labels run beyond the packet’s evidence.

RFC 9001 §5.8 defines the narrow guarantee. The 128-bit tag is produced with AEAD_AES_128_GCM over an empty plaintext. Its associated data is a pseudo-packet made from the Retry without its tag, prefixed by the length and value of the Original Destination Connection ID, or ODCID. QUIC version 1 specifies the key and nonce used for that calculation. Because the ODCID came from the client’s Initial, a valid tag establishes that the sender observed that Initial. It also lets the client reject accidental corruption.

That is not peer authentication. The fixed inputs needed to calculate the version 1 tag are in the public specification, while the Retry packet has no protected fields. A valid tag therefore cannot substitute for the certificate and Finished evidence from the TLS handshake. It does not identify which server instance produced the packet, whether that instance was authorised for the service name, or whether an on-path system sent the Retry.

RFC 9000 §17.2.5 gives the client the next mechanical test. It must discard a Retry whose tag cannot be validated or whose token is empty, and it processes at most one Retry per connection attempt. If accepted, the client sends another Initial using the Retry source connection ID as its destination connection ID and copies the Retry token into that Initial. The observed Retry is thus a request for a return-path proof, not the completed proof.

The server-side boundary appears in RFC 9000 §8.1.2. When a client returns a token that an attacker cannot generate for its own address, the server can establish that the client received it. The server still has to validate the returned token and decide whether to refuse the connection or let it proceed. A capture that ends at the outbound Retry cannot prove token acceptance or completed validation of the client address.

For operations, keep a joined receipt rather than a “Retry valid” flag: QUIC version, original five-tuple and timestamp, ODCID, Retry DCID and SCID, exact Retry bytes, tag result, token fingerprint, the subsequent Initial’s tuple and time, returned-token fingerprint, server validation result, validation domain or instance, TLS certificate and Finished result, and final connection outcome. These fields expose anycast secret drift, token expiry, path changes and misrouted validation without turning a limited cryptographic check into an identity claim.