Caching CMM MUST NOT call underlying CMM with plaintext length specified

[lavaleri]

Problem: The CMM interface doesn't make any guarantees on the EncryptionMaterials returned based on the plaintext length (nor does the Caching CMM). However, one could construct a specific CMM implementation that does. If the Caching CMM uses such a CMM as it's underlying CMM, and that underlying CMM performs some plaintext specific logic to produce a set of encryption materials which then get cached, that is bad.

Solution: specify the following: A Caching CMM, when calling it's underlying CMM, MUST NOT pass on this value to the underlying CMM, and instead leave it unspecified.

[seebees]

As a counterpoint, perhaps the right thing for the caching CMM to do is to pass the byteLimit. While it is true that this specific plaintext length is NOT the right answer, this maximum is?

[mattsb42-aws]

The plaintext length is a statement of what is being encrypted.
The byte limit is a statement of how the caching CMM will or will not reuse data keys across messages.
These are very different things and we should not attempt to merge them.

[SalusaSecondus]

I think that arguments can be made in either direction. Treating the "plaintext length" as passed to a CMM as a statement of "This is how many bytes I intend to encrypt with the key you give me" is not unreasonable and lets upstream CMMs make more reasonable decisions than simply receiving "I have no idea as to the plaintext length."

While it is a completely artificial example, passing on byteLimit to the upstream CMM would allow chained caching CMMs to act correctly. This suggests that there is merit to this position.