Summary

  • RFC 9709 derives the working content-encryption key from both the original content-encryption key and the exact DER encoding of the inner AlgorithmIdentifier, including parameters.
  • Changing an authenticated algorithm label or its parameters therefore changes the key. The recipient gets unusable output rather than a useful CBC plaintext oracle.
  • The control protects confidentiality against this transformation; it does not prove who sent the message, whether the content is safe, or whether downstream action is authorized.

A label that had become an input

The dangerous assumption was that an algorithm identifier merely described how to use a key. In the attack considered by the IETF LAMPS working group, an interceptor takes CMS content protected with an authenticated-encryption mode such as AES-GCM or AES-CCM and recasts selected ciphertext blocks as AES-CBC content. The underlying key is not recovered. Instead, the victim's software becomes an inverse oracle: if it processes the altered object and exposes the result, an attacker can test guesses about structured, low-entropy plaintext.

This is not a universal instant-decryption machine. The IETF presentation that preceded the standard stressed practical limits: an S/MIME message may turn into obvious garbage; applications may reject a malformed header; the vulnerable systems in deployment were not known. But those limits are environmental, not a cryptographic boundary. A different CMS application can disclose a status, error, parsed field or downstream effect that makes the guess useful.

RFC 9709 makes the description inseparable from key use. A capable recipient advertises id-alg-cek-hkdf-sha256 in its S/MIME capabilities, with absent parameters. When a sender selects the mitigation, the outer contentEncryptionAlgorithm is that identifier. Its required parameter carries the actual inner content-encryption AlgorithmIdentifier: the cipher and its parameters that will process the content.

The sender and recipient then derive a new working key, CEK-prime, with HKDF-SHA-256. The original content-encryption key is the input keying material. The salt is the fixed ASCII string “The Cryptographic Message Syntax”. The HKDF info input is the full DER encoding of the inner algorithm identifier—sequence tag, length, object identifier and encoded parameters. Output length equals the original key length, up to HKDF's 8,160-byte SHA-256 limit.

That exactness is the point. Replace GCM with CBC, alter an initialization vector, or otherwise change the encoded inner algorithm and the recipient derives a different key. Ciphertext crafted for the original key is no longer a useful experiment under the attacker's chosen interpretation. If an attacker simply strips away the outer mitigation identifier, the recipient uses the original key rather than CEK-prime. The message becomes inaccessible, but it still does not yield the protected plaintext. Confidentiality failure has been converted into denial of access.

Seven decisions, not one “decrypt” result

Operational evidence should preserve the boundaries that the protocol preserves.

First is capability: did the recipient advertise support for the mitigation? Second is the outer mitigation OID: did the sender actually select it? Third is the carried inner algorithm and its parameters. Fourth is derivation: were the exact DER bytes bound into HKDF? Fifth is cryptographic processing: did authenticated decryption and associated-data verification succeed where the inner mode requires them? Sixth is disclosure: did any plaintext, parser output or behavioral signal leave the trust boundary? Seventh is downstream policy: is the resulting message permitted to trigger storage, rendering, workflow or human action?

Collapsing those records into “decryption succeeded” destroys the evidence needed to distinguish a compatibility fault from a manipulation attempt. Conversely, successful parsing is not proof of authorship. RFC 9709 is a key-separation measure, not a signature, reputation system, malware filter or authorization decision.

The same caution applies to authenticated attributes. RFC 9709 notes that an unencrypted message-digest attribute can help an observer confirm a plaintext guess. Encrypted unsolicited content may also pass around controls designed to inspect spam or phishing. An approved-originator list is one possible compensating policy, but it answers a different question from algorithm binding.

Minimal coordination, local verification

The design deliberately fixes SHA-256 for this construction rather than creating a KDF negotiation surface. A future hash function would receive a new object identifier. That keeps the common specification narrow while giving each endpoint a deterministic verification rule: parse the outer construction, retain the exact inner encoding, derive, then authenticate or decrypt according to the inner algorithm.

It also leaves ordinary key hygiene untouched. Content-encryption keys still need high-quality randomness and protection. The CMS structures defined by RFC 5652, authenticated-enveloped-data from RFC 5083, AEAD conventions in RFC 5084, HKDF in RFC 5869, S/MIME capabilities in RFC 8551 and randomness guidance in RFC 4086 remain separate dependencies. RFC 9709 does not turn a weak key, compromised endpoint or misleading sender identity into a trustworthy system.

At the time of this review, the RFC Editor errata search showed no reported RFC 9709 errata. IANA's SMI registry records the assigned module and algorithm identifiers. Those publication facts establish the coordination state; deployed behavior still has to be measured.

Sources