Change:
16. <del> The primary purpose of the Handshake protocol is to provide an </del> <ins> The primary purpose of handshake messages are to provide an </ins> authenticated group key exchange to clients.  In order to protect <del> Application messages sent among the members of a group, the Application secret provided by the Handshake key schedule is used to derive nonces and encryption keys for the Message Protection Layer according to the Application Key Schedule.  That is, each epoch is equipped with a fresh Application Key Schedule which consist of a tree of Application Secrets as well as one symmetric ratchet per group member. Each client maintains their own local copy of the Application Key Schedule for each epoch during which they are a group member.  They derive new keys, nonces and secrets as needed while deleting old ones as soon as they have been used. Application messages MUST be protected with the Authenticated- Encryption with Associated-Data (AEAD) encryption scheme associated with the MLS ciphersuite using the common framing mechanism.  Note that "Authenticated" in this context does not mean messages are known to be sent by a specific client but only from a legitimate member of the group.  To authenticate a message from a particular member, signatures are required.  Handshake messages MUST use asymmetric signatures to strongly authenticate the sender of a message. </del> <ins> application messages sent among the members of a group, the "encryption_secret" provided by the key schedule is used to derive a sequence of nonces and keys for message encryption.  Every epoch moves the key schedule forward which triggers the creation of a new secret tree, as described in secret-tree, along with a new set of symmetric ratchets of nonces and keys for each member. Each client maintains their own local copy of the key schedule for each epoch during which they are a group member.  They derive new keys, nonces, and secrets as needed while deleting old ones as soon as they have been used. The group identifier and epoch allow a recipient to know which group secrets should be used and from which "epoch_secret" to start computing other secrets.  The sender identifier and content type is used to identify which symmetric ratchet to use from the secret tree. The "generation" counter determines how far into the ratchet to iterate in order to produce the required nonce and key for encryption or decryption. </ins> 16.1. <del> The group members MUST use the AEAD algorithm associated with the negotiated MLS ciphersuite to AEAD encrypt and decrypt their Application messages according to the Message Framing section. The group identifier and epoch allow a recipient to know which group secrets should be used and from which Epoch secret to start computing other secrets and keys.  The sender identifier is used to identify the member's symmetric ratchet from the initial group Application secret.  The application generation field is used to determine how far into the ratchet to iterate in order to reproduce the required AEAD keys and nonce for performing decryption. Application messages SHOULD be padded to provide some resistance against traffic analysis techniques over encrypted traffic.  CLINIC HCJ16 While MLS might deliver the same payload less frequently across a lot of ciphertexts than traditional web servers, it might still provide the attacker enough information to mount an attack.  If Alice asks Bob: "When are we going to the movie ?" the answer "Wednesday" might be leaked to an adversary by the ciphertext length.  An attacker expecting Alice to answer Bob with a day of the week might find out the plaintext by correlation between the question and the length. </del> <ins> Application messages MAY be padded to provide some resistance against traffic analysis techniques over encrypted traffic CLINIC HCJ16. While MLS might deliver the same payload less frequently across a lot of ciphertexts than traditional web servers, it might still provide the attacker enough information to mount an attack.  If Alice asks Bob "When are we going to the movie?", then the answer "Wednesday" could be leaked to an adversary solely by the ciphertext length. </ins> The length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  Senders may

Discussion:
Interim 2022-05-26: Intended to be mostly editorial Leaving open for now Clear to merge in between meetings if folks are comfortable
Interim 2022-06-02: Still clear from last week
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.
This is stated in 10.1:
I suspect that what Raphael is worried about is that a malicious insider (someone in possession of the ) could make an MLSCiphertext with set to that would cause the receiver to do 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 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. A figure here might also be helpful.
Couple of friendly amendments, otherwise lgtm. I am going to hold this as slightly more than editorial, given the number of MUSTs that are affected. But I would note for others that the MUSTs that are removed here are all redundant with requirements above.Thanks for picking this up! Just one nit, but looks good otherwise.