Summary

  • TLS 1.3 made traffic-key renewal a narrow, directional operation: one sender advances its write secret, and the peer advances the matching receive secret. The opposite direction changes only through a separate update.
  • Deleting older generations can protect earlier traffic from a later disclosure, but the chain runs forward from the current secret. If that secret is compromised, repeated KeyUpdate messages do not create post-compromise recovery.

A connection can outlive a key budget

The easiest mental model of TLS begins and ends with a handshake. Two endpoints agree on a protocol version and cipher suite, authenticate as required, derive keys and then exchange protected records. That picture is sufficient for a short transaction. It becomes incomplete when the protected channel carries a persistent API session, a long download, an HTTP/2 connection with many streams or another workload that can spend an enormous number of records under one set of traffic keys.

Authenticated-encryption algorithms do not have an infinite safe-use allowance. Their confidentiality and integrity bounds depend on how much data is processed under a key and on the construction’s failure probabilities. TLS 1.3 therefore tells implementations to update keys before reaching applicable usage limits. Later operational guidance in RFC 9325 likewise asks long-lived applications to consider how session keys will be refreshed.

Earlier TLS versions could renegotiate. That was a broad mechanism: it reopened negotiations inside an existing connection and could entangle fresh key material with authentication and protocol state. TLS 1.3 removed renegotiation. In its place it retained smaller post-handshake operations with smaller mandates. KeyUpdate does not negotiate another version, choose another cipher suite, replace a certificate or reopen application identity. It advances the keys used for application traffic.

The update message belongs to the old generation

The exact boundary is part of the design. A sender transmits KeyUpdate under its current write keys. Every record it sends after that message uses newly derived write keys. The receiver reads and authenticates the message with its current receive state, then advances the corresponding receiving secret before processing the records that follow.

This ordering makes the update an authenticated instruction inside the protected sequence. It is not an out-of-band toggle and not a timestamp both sides must guess. Yet it also means implementations have to preserve the order of the record stream at the generation boundary. Switching too early makes the update message unreadable; switching too late makes the first new-generation record fail.

The derivation rule is directional. Client application traffic and server application traffic already have distinct secrets. When one endpoint updates its sending keys, only that write direction and the peer’s matching receive direction move to the next generation. Traffic travelling the other way remains under its own current secret.

That asymmetry is not a temporary flaw to be hidden by the interface. It is the protocol’s state model. An endpoint can send an update with update_not_requested, changing only its outgoing side. With update_requested, it also asks the peer to send a KeyUpdate response. The requested response is a second protected message and a second directional transition; it does not make the first message rotate both directions at one instant.

The standard anticipates crossed requests. Both endpoints may independently ask for an update while their messages are in flight, and each still has to answer correctly. But an endpoint must not issue another request before receiving the response to the one already outstanding. It must also reject an update sent before the handshake’s Finished message and impose a bound against peers that send excessive updates. Renewal is permission to advance cryptographic state, not permission to consume unlimited remote work.

Forward derivation protects the past, not the future

After an update, the old traffic secret can be deleted once it is no longer needed to process the transition. That deletion has a valuable consequence. If an attacker later obtains a newer traffic secret, the one-way derivation does not hand the attacker the older generations. Previously recorded ciphertext can remain outside the reach of the later disclosure.

The reverse claim is false. A party that learns the current traffic secret can calculate later traffic secrets derived from it. Asking the connection to update again merely moves along a chain whose present link is already known. KeyUpdate injects no independent entropy and performs no new authentication. It is key-use rotation and past-key retirement, not a healing ritual for a live compromise.

This distinction is operationally decisive. A counter approaching an AEAD usage limit is a reason to advance the generation. Evidence that the current traffic secret has escaped is a reason to terminate the affected connection and establish fresh secrets through a new handshake. Treating those events as equivalent can preserve an attacker’s access indefinitely while dashboards report reassuring rotation activity.

HTTP/2 could tolerate the narrow operation

Multiplexing reveals why narrowing mattered. An HTTP/2 connection can carry many concurrent requests. A connection-wide identity change after the handshake creates an attribution problem: which streams were sent under which authenticated identity, and when did the meaning change? RFC 9113 therefore prohibits TLS 1.3 post-handshake authentication for HTTP/2.

The same specification permits KeyUpdate. Updating record-protection secrets does not by itself change the identity or authorization meaning of any HTTP request. Streams continue; the cryptographic generation beneath one traffic direction advances. The operation works precisely because its authority is smaller than renegotiation’s.

QUIC draws a different boundary. It uses TLS to establish secrets, but RFC 9001 forbids sending TLS KeyUpdate messages over QUIC. Datagram packets can be reordered, so QUIC performs its own update using the Key Phase bit and acknowledgement-aware rules. The objective—limit use of one key and retire older material—is shared. The stream-ordered TLS message is not universal transport machinery.

A small message with a precise jurisdiction

KeyUpdate does not prove that a peer is still trustworthy, reauthorize a user, reset an application session or erase evidence of compromise. Its jurisdiction is the protected record layer of one continuing connection. It gives that layer an explicit sequence of traffic-key generations and lets each direction move when needed.

That modest scope is its historical achievement. TLS 1.3 did not replace renegotiation with another all-purpose ceremony. It separated a recurrent cryptographic maintenance task from identity and application state—and, in doing so, made the limits of “rotation” visible.

Sources and limits

This account relies on RFC 8446, RFC 9001, RFC 9113 and RFC 9325. They specify protocol behavior and operational considerations; they do not establish current product support, deployment share, library defaults or a universal update interval.