Summary

  • Revision 13 explicitly counts associated authenticated data with plaintext volume. A service that meters only ciphertext payload has not measured the quantity the bound describes.
  • Protected messages, failed verification attempts, nonce reuse, the total key population and the greatest exposure under any one key are different facts. A process-local or connection-local counter can lose their common scope.
  • The draft offers formulas and illustrative examples, not a universal rotation interval. The application owns the target risk; the deployment must prove counting, refusal, activation and retirement in running code.

A research result is not an operating meter

The Crypto Forum Research Group posted revision 13 of Usage Limits on AEAD Algorithms on 3 September 2026. The document now states that it is a product of CFRG consensus, but it remains an IRTF Internet-Draft. It can change, expire or never become an RFC.

Its central observation is older than the revision and easy to flatten into a slogan: authenticated encryption becomes less secure as the same key is used more. The useful work starts where the slogan ends. “Use less” has to become a measurable admission rule for a particular construction, risk tolerance and deployment shape.

RFC 5116 gives applications a common AEAD interface: key, nonce, plaintext and associated data go in; ciphertext and a success or failure result come out. That interface does not operate a fleet-wide budget. It does not know how many replicas share the accounting domain, whether counters survive restart, which rejected packets reached verification, or whether two connections belong to the same multi-key analysis.

Revision 13 therefore matters as a control-plane clarification. The formula is common technical knowledge. The decision about acceptable risk and the evidence that the formula governs live traffic remain local responsibilities.

The application chooses what “small enough” means

The draft distinguishes authenticated-encryption advantage, confidentiality advantage and integrity advantage. In plain terms, each is a bound on how much better an attacker can do than the idealized baseline under a defined experiment. The application chooses acceptable targets, then derives limits from those targets and its parameters.

That order is crucial. A vendor cannot lift a row from an example table, put it in a rotation job and call the result compliant. The examples assume particular message sizes, offline work and target advantages. Change those assumptions and the permitted counts change. Choose a construction with a shorter tag and failed verification may become the first exhausted resource.

The owner of the application must state the risk target, the construction and tag length, the message-size envelope, the offline-work assumption and whether the system is being treated as one key or many. Otherwise a number in a dashboard has no reviewable meaning.

AAD spends budget even when it is not payload

Revision 13 changes the notation for total volume s from plaintext alone to plaintext plus associated authenticated data. It also defines maximum message length L over both. This is not a cosmetic edit.

AAD is not encrypted, but it is authenticated. Protocol headers, sequence information, context labels or routing metadata may enter the authentication computation without appearing in the encrypted body. A telemetry system that bills only application payload can report room remaining while the cryptographic construction has processed more work than the meter records.

CCM makes the accounting boundary especially legible. The underlying block-cipher work includes associated data, ciphertext and plaintext, plus an additional operation. The draft uses a conservative 2L approximation for the effective message work. The exact formula belongs to the construction; the operational lesson travels further: visible payload bytes are not automatically the security quantity.

The same separation applies to records and receipts. Operators need the exact algorithm, tag length and key identifier, plus lengths that include authenticated context. A traffic graph without those joins is capacity telemetry, not a cryptographic budget.

Success and rejection spend different authority

The draft uses q for protected messages and v for unsuccessful decryption or forgery attempts. Those numbers are produced on opposite sides of the service. Successful writers know what they encrypted. Verifiers see invalid ciphertexts, bad tags and adversarial submissions. One team or process may not observe both.

That division creates a familiar failure. Encryption counters rotate a key according to outbound volume, while a fleet of readers absorbs failed verification against the same key without contributing to the threshold. The service then enforces a confidentiality budget and silently ignores the integrity budget.

The short tag in AES-CCM_8 shows why the distinction can dominate. Revision 13 explains the different allocation of protected-message and failed-verification limits and retains an illustrative v value of 2^13 under one example. That figure is not general guidance. Its importance is structural: a shorter tag can make hostile failures, rather than successful traffic, the scarce resource.

A correct refusal path must therefore count an attempt before discarding its application value. Rate limiting may reduce exposure, but a rate-limit dashboard is not the counter unless it covers the exact verification operations and key scope in the analysis.

One key and many keys are different systems

Section 6 covers single-key limits. The draft expressly says those limits must not be used where multiple keys are deployed, including rekeying within one connection or multiple connections between two parties. Section 7 treats the multi-key setting, where the attacker is satisfied by breaking any key in the population.

This breaks the intuition that more rotation automatically makes accounting simpler. Rekeying reduces work under one key, but it also creates a larger key population. Multi-key analysis needs aggregate protected and failed operations, and for some constructions it also needs the maximum blocks processed under any one key: B for encrypted blocks or C for encrypted and decrypted blocks.

A fleet total alone can hide a hot key. Per-key counters alone can hide the advantage of targeting any key in a large population. A correct control plane preserves both views and the definition of which keys belong together.

The scope cannot be allowed to follow an observability convenience. A pod restart, regional failover, tenant move or dashboard migration must not mint a fresh budget unless the cryptographic model actually creates a new independent scope. The key identifier, counter domain and analysis must survive the operational topology.

Nonce discipline is a separate gate

The draft focuses on schemes requiring non-repeating nonces. For GCM, repeating a nonce with the same key can have serious confidentiality and integrity consequences. A usage counter below its threshold does not excuse a duplicate key/nonce pair.

Nonce allocation therefore needs its own receipt: who assigns it, how uniqueness survives concurrency, crash and rollback, and how the receiver detects or contains violations. Rotation after a duplicate is an incident response, not proof that the previous operation was safe.

Revision 13 also clarifies that GCM’s s + q + v < 2^64 condition can become the binding constraint when the probability-derived term approaches that ceiling. This is another warning against operating one headline counter. The first applicable constraint governs admission.

Rotation has four moments

A scheduled key-manager task does not show when running writers switched. Operationally, rotation has at least four distinct moments: a new key is created, distributed, activated for protection and later retired from acceptance. Readers may need the old key after writers have stopped using it. In-flight work may straddle the change.

The budget gate belongs before protection work is admitted. It needs enough headroom for delayed telemetry, concurrent reservations, retries and operations already in flight. If the counter service is unavailable, leadership must have chosen whether the cryptographic path fails closed, falls back to a smaller local allowance or accepts an explicitly bounded emergency risk.

Retirement is equally important. Keeping an old key indefinitely enlarges the active population and the evidence burden. Removing it too early can turn valid late traffic into failed verification, which may itself spend a scarce v budget. Rotation and retirement are related decisions, not one timestamp.

What revision 13 does not prove

The source packet contains no test of a TLS stack, QUIC endpoint, device fleet, cloud service, VPN, database or key manager. RFC 8446 and RFC 9001 show relevant nonce-randomizing protocol contexts; they do not show that a deployment implements the draft’s accounting.

A successful handshake identifies negotiated parameters, not remaining key authority. A valid authentication tag proves one cryptographic check, not that earlier volume or failures were counted. A key-rotation log proves an administrative event, not that every writer stopped using the old key. No incident, compromise, adoption level or benchmark follows from the standards record.

The draft’s value is narrower and stronger: it supplies a disciplined vocabulary for asking what the deployment must prove.

Sources