What actually happens during a TLS 1.3 KeyUpdate, and why isn't it the same as renegotiation?

What actually happens during a TLS 1.3 KeyUpdate, and why isn't it the same as renegotiation?

The distinction matters because TLS 1.3 deliberately killed renegotiation — a feature with a long abuse history — and replaced it with something narrower.

TLS 1.2 renegotiation let either party run a fresh handshake inside an existing connection, re-authenticating or rekeying mid-stream. It enabled the 2009 renegotiation attack (CVE-2009-3555), where injected plaintext was spliced ahead of a client's authenticated request. RFC 5746 patched it, but the complexity remained.

TLS 1.3 (RFC 8446 §4.6.3) removes renegotiation entirely. For rekeying it offers KeyUpdate: a post-handshake message saying "derive the next traffic key." The new application-traffic secret is computed by applying HKDF-Expand-Label with the label "traffic upd" to the current secret — a one-way ratchet forward. No new key exchange, no re-authentication, no transcript renegotiation. KeyUpdate can request the peer also update (update_requested), giving bidirectional rekey.

What it cannot do is change identities or parameters. That deliberate limitation is the security gain: there is no in-band way to re-handshake, so the renegotiation attack surface is structurally absent. Re-authentication, where needed, is handled separately via post-handshake authentication (CertificateRequest), not by rekeying.

KeyUpdate exists mainly to bound the data encrypted under a single key, respecting AEAD usage limits.

Further reading: RFC 8446 §4.6.3, §4.6.2; RFC 5746; CVE-2009-3555.

Bottom line: KeyUpdate ratchets traffic keys forward via HKDF without any new handshake — it rekeys but, unlike renegotiation, cannot re-authenticate or re-parameterize, which is precisely why it's safe.