Content encryption: Clarify generation sequence

[raphaelrobert]

The generation numbers should be increased sequentially, gaps should be avoided to avoid unnecessary expensive operations on clients. Clients might also abort if the gap is too large to prevent attacks from malicious insiders.

[Bren2010]

This is stated in 10.1:

The sender uses the j-th key/nonce pair in the sequence to encrypt (using the AEAD) the j-th message they send during that epoch.

[bifurcation]

I suspect that what Raphael is worried about is that a malicious insider (someone in possession of the sender_data_secret) could make an MLSCiphertext with generation set to 0xffffffff that would cause the receiver to do 2^32-1 HKDF invocations. The attacker doesn't have to incur this cost because they don't need to generate the required key -- the ciphertext can be garbage because the key generation happens before the decryption does.

It seems like we could use a paragraph at the end of {{encryption-keys}} covering this and the fact that if you want to allow for out-of-order messages, you need to keep the intermediate keys. Since big gaps would force you to store the keys as well as doing the hashing.

Clients might not receive messages in the order they are sent. In order to allow for decryption of out-of-order messages, clients MAY retain keys and nonces for generations earlier than the latest received generation. clients MAY impose a limit on the size of gaps they will allow in the generation sequence, in order to avoid generating and/or storing large numbers of such keys and nonces.

A figure here might also be helpful.