Summary

  • A changed Key Phase bit is only an apparent update until the packet is successfully processed with the next key and IV.
  • That success proves the peer initiated a key update on this connection, not why it did so or whether old keys were erased.
  • Operators need the packet, key-generation, acknowledgment, deployment and policy records together before assigning cause.

A transport dashboard records a Key Phase change during a software rollout. The incident channel calls it a security rotation. The timing may be suggestive, but the bit does not carry that explanation.

RFC 9001 §6 gives the Key Phase bit a precise job: it identifies the packet-protection key generation used for a 1-RTT packet. It starts at zero and toggles for every later update. QUIC uses this mechanism instead of the TLS KeyUpdate message. The signal says which keys should work, not what operational decision caused their use.

The proof boundary arrives in §6.2. A receiver seeing the opposite phase tries the next key and IV. Only successful processing establishes that the peer initiated an update. The receiver then updates its own send keys before acknowledging that packet; an acknowledgment protected with updated keys signals completion. A trace that exposes only the phase bit but not successful decryption therefore records an apparent transition, not a confirmed one.

Sequencing matters. Section 6.1 forbids initiation before handshake confirmation and forbids a further update until a packet in the current phase has been acknowledged. The header-protection key does not change. Old packet-protection keys must be retained until a packet under the new keys is successfully unprotected, and should remain briefly afterward because reordered packets can still arrive.

Sections 6.3 and 6.5 explain why an endpoint may hold current, next and previous receive keys while avoiding timing signals. A forged phase bit can trigger work; failed decryption is not proof of either a legitimate update or an attack.

For incident attribution, preserve an evidence receipt: endpoint role, connection fingerprint, packet number, phase, decrypt result, read and write generations, handshake-confirmed time, triggering packet, updated-key acknowledgment, retention window, implementation build, deployment epoch and key-policy audit event. The protocol can prove cryptographic continuity. The surrounding records must explain intent and cause.