Specification Message Body: Inconsistency size encrypted content in regular frame

[WouterSchols]

The specification aws-encryption-sdk-specification/data-format/message-body.md section Framed Data subsection Regular Frame contains the following requirement:

Encrypted Content

The encrypted data for each frame, as returned by the encryption algorithm.
The length of the encrypted content of a Regular Frame MUST be equal to the Frame Length.

This requirement states that the size of the encrypted content in one frame must equal to Frame Length. However Frame Length is defined as the amount of plain text which we want to encrypt in one regular frame. The size of the content which we want to encrypt does not have to be equal to the size of the encrypted content. Because of this the requirement is inconsistent.

Solutions would be adding a requirement to the encryption algorithm that the size of the plain text is equal to the encrypted content or we removing this requirement. Note that there should be some upper limit on the size of the encrypted content to prevent frames from getting too big.

[mattsb42-aws]

Thanks for finding this gap!

I think that having the encrypted content length == frame size required in the data format makes sense because if that is not true then we cannot know how to unpack a frame.

The other place that we might need to put this is in the algorithm suite spec: Stating restrictions on what frame sizes different algorithm suites support. Currently, all of our suites can support any frame length, but that won’t always be true. The client needs to enforce that, but I think that the place where the “knowledge” needs to live is in the algorithm suite.

[lavaleri]

Agreed on the above recommendation to update the algorithm suite.

If we do add an encryption algorithm that does not have this property in the future, any algorithm suite using that new encryption algorithm will not be compatible with message format v1.0. I'm unsure how we want to communicate this now.

Should we note in the algorithm suite spec that, as of message format 1.0, all encryption algorithms need to have this property? Or do we preemptively mark which versions are compatible with algorithm suite right now?

[mattsb42-aws]

I think that saying for now that all suites MUST have this property is fine. I think an intermediate step that we could take that would not require a format change would be to add the requirement that algorithm suites MUST define which frame sizes they support. For example, if we were to add a suite that used a padded encryption algorithm/mode, the existing format could support that as long as the frame size is a multiple of the algorithm's block size. The specific requirements for something like this vary between algorithms and modes that an algorithm suite could define, so I think that is the correct place to put this decision.

[seebees]

+3. Document the limitation. I do not think that it is the worst limitation to have.
When we consider a new message format this is yet another thing to put on the pile.