Visual RFC.
ALL RFCs / RFC 9846
Read the RFC ↗
RFC 9846 / MECHANISMS

Update before key limits

04

A traffic key has a finite usage bound and must be replaced before exceeding it.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 5.5 ↗
RFC 9846 · § 5.5EXAMPLE
3 / 3
Update before key limitsA traffic key has a finite usage bound and must be replaced before exceeding it. Current state: Next key.Update before key limitstraffic key nusage boundnew key · sequence resetKeyUpdate with old keyUse next traffic secret before the boundThe bound depends on the AEAD; this gauge has no numeric scale.
03
Next key

Use the next traffic secret and reset the record sequence for the new key.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
WHAT CHANGED
RFC 8446 key-usage guidanceRFC 9846 § 1.2

The revision makes initiating key update before exceeding usage limits mandatory and limits KeyUpdate message behavior.

Read the updated RFC section ↗
KEY POINT

An implementation must initiate a key update before reaching its applicable usage limit.

  • An implementation must initiate a key update before reaching its applicable usage limit.
  • The usage bound depends on the AEAD algorithm and security target.
  • KeyUpdate messages themselves are protected with the old key before moving to the new sending key.
DETAILS

The illustration is schematic. Example values are illustrative; profiles and later security guidance can add requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. The protected handshake
  2. Fresh key shares for each connection
  3. Retry stays in the transcript
  4. Update before key limits
  5. Early data still needs replay handling
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗