Original text:
15.2.  MLS does not provide confidentiality protection to some messages and fields within messages: as a guide to understanding how they might be exposed or protected in a given application. <del> 15.2.1. </del>  MLS provides no mechanism to protect the group ID and epoch of a message from the DS, so the group ID and the frequency of messages and epoch changes are not protected against inspection by the DS. <del> 15.2.2. </del>  A group's extensions are first set by the group's creator and then updated by GroupContextExtensions proposals.  A GroupContextExtension confidential to the group and the new joiner, then it will leak the group's extensions. <del> 15.2.3. </del>  The group's membership is represented directly by its ratchet tree, since each member's LeafNode contains members' cryptographic keys, a node to be less identifying, e.g., by using a pseudonymous credential and frequently rotating encryption and signature keys. <del> 15.3. </del>  The first form of authentication we provide is that group members can verify a message originated from one of the members of the group. that ensures that the legitimate members of the group have the required PSKs. <del> 15.4. </del>  Forward secrecy and post-compromise security are important security notions for long-lived MLS groups.  Forward secrecy means that This way, the key material used to add a member to a new group is more likely to be fresh and less likely to be compromised. <del> 15.5. </del>  KeyPackages are intended to be used only once.  That is, once a KeyPackage has been used to introduce the corresponding client to a KeyPackage publication system SHOULD rate-limit KeyPackage requests, especially if not authenticated. <del> 15.6. </del>  It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath "SHA384", and "SHA512" refer to the SHA-256, SHA-384, and SHA-512 functions defined in SHS.  It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only include modern, yet well-established

Reviewer comments:
I would propose we say that we need AE1 security for our AEAD scheme, which gives us random ciphertexts and if we have random ciphertexts the input to key/nonce generation for sender data encryption is unique. This in turn gives us AE1 security for sender data encryption. I don't think we need AE2 encryption because our nonces are random and don't reveal any private information. Also, if I understand correctly, AES GCM is not AE2 secure, so if we want AE2 security, we need a different scheme or the transform described in NAN. Probably needless to say, but I don't have a security proof for any of this. So more eyes on whatever we write here would be appreciated.
Comment by NAME I don't think I understand the security model here? What happens if the previous ciphertext has 00's for the first KDF.Nh bytes?
The ciphertext sample here is just acting as a salt to produce several distinct key/nonce pairs from a single . So as with , all-zeros isn't inherently harmful here, unless it happens repeatedly. (Note that this scheme was inspired by , except the latter only uses 16 bytes of sample and XOR instead of AEAD.) If the content encryption is done properly, then the probability of any particular value is vanishingly small, due to the ciphertext looking like random data. Someone could construct a ciphertext that results in nonce reuse, e.g., having the same bytes as a previous message. However, note that the harm here is done when the reused key/nonce is used to encrypt and the encrypted sender info is published to the attacker. This means that the attack cannot be mounted from outside the group. Even if the attacker can cause a sender to encrypt a given plaintext, the attacker would not know the key with which it would be encrypted. So the best attack is for an insider to the group to leak the sender info. cc NAME who did some analysis on this IIRC
I didn't do analysis on this, however I'm a bit concerned by the assertion "due to the ciphertext looking like random data". I don't think this is a standard security assumption we do on AEADs? For example if I take a secure AEAD, and build a new one by prefixing zeroes, the new AEAD is as secure as the original one? To make sure that there is no key/nonce re-use, I think it would be better to use a full hash on the ciphertext, but it increases computation cost.
Yeah, I'm also a bit wary of this assumption. I think this would correspond to -IND-CCA security for the AEAD scheme. Wasn't this inspired by QUIC somehow (maybe header encryption)? In any case, if we don't do so already, we might want to explicitly note this in the ciphersuite section to ensure that AEAD schemes added in the future indeed produce pseudorandom ciphertexts.
It also occurs to me that is only 12 bytes long (and 12 < 16), so we could change this to literally do what QUIC does: (And there's a parallel for ChaCha) That would more clearly benefit from any QUIC analysis, and would save an extra auth tag. It would be a minor pain to implement, because you would need access to a raw cipher as well as an AEAD mode.
It looks like it also relies on the ciphertext prefix being random? I dislike this approach which is too low-level in my opinion, I would prefer staying with high-level cryptographic primitives.
I filed to try to address this. Basically, I argue that the same arguments from Bellare et al. that apply to QUIC header protection also apply here. The PR also adds a requirement that AEADs act as PRFs, as discussed here.

Revised text:
15.2. <ins> The MLSCiphertext framing encrypts "sender data" that identifies which group member sent an encrypted message, as described in sender- data-encryption.  As with the QUIC header protection scheme RFC9001, Section 5.4, this scheme is a variant of the HN1 construction analyzed in NAN.  A sample of the ciphertext is combined with a "sender_data_secret" to derive a key and nonce that are used for AEAD encryption of the sender data. "pseudocode (key, nonce) = PRF(sender_data_secret, sample) encrypted_sender_data = AEAD.Seal(key, nonce, sender_data_aad, sender_data) " The only differences between this construction and HN1 as described in NAN are (1) that it uses authenticated encryption instead of unauthenticated encryption and (2) that it protects information used to derive a nonce instead of the nonce itself. Since the "sender_data_secret" is distinct from the content encryption key, it follows that the sender data encryption scheme achieves AE2 security as defined in NAN, and therefore guarantees the confidentiality of the sender data. Use of the same "sender_data_secret" and ciphertext sample more than once risks compromising sender data protection by reusing an AEAD (key, nonce) pair.  For example, in many AEAD schemes, reusing a key and nonce reveals the exclusive OR of the two plaintexts.  Assuming the ciphertext output of the AEAD algorithm is indistinguishable from random data (i.e., the AEAD is AE1-secure in the phrasing of NAN), the odds of two ciphertext samples being identical is roughly 2 , i.e., the birthday bound. The AEAD algorithms for ciphersuites defined in this document all provide this property.  The size of the sample depends on the ciphersuite's hash function, but in all cases, the probability of collision is no more than 2 .  Any future ciphersuite MUST use an AE1-secure AEAD algorithm. 15.3. </ins> MLS does not provide confidentiality protection to some messages and fields within messages: as a guide to understanding how they might be exposed or protected in a given application.  <ins> 15.3.1. </ins> MLS provides no mechanism to protect the group ID and epoch of a message from the DS, so the group ID and the frequency of messages and epoch changes are not protected against inspection by the DS.  <ins> 15.3.2. </ins> A group's extensions are first set by the group's creator and then updated by GroupContextExtensions proposals.  A GroupContextExtension confidential to the group and the new joiner, then it will leak the group's extensions.  <ins> 15.3.3. </ins> The group's membership is represented directly by its ratchet tree, since each member's LeafNode contains members' cryptographic keys, a node to be less identifying, e.g., by using a pseudonymous credential and frequently rotating encryption and signature keys.  <ins> 15.4. </ins> The first form of authentication we provide is that group members can verify a message originated from one of the members of the group. that ensures that the legitimate members of the group have the required PSKs.  <ins> 15.5. </ins> Forward secrecy and post-compromise security are important security notions for long-lived MLS groups.  Forward secrecy means that This way, the key material used to add a member to a new group is more likely to be fresh and less likely to be compromised.  <ins> 15.6. </ins> KeyPackages are intended to be used only once.  That is, once a KeyPackage has been used to introduce the corresponding client to a KeyPackage publication system SHOULD rate-limit KeyPackage requests, especially if not authenticated.  <ins> 15.7. </ins> It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath "SHA384", and "SHA512" refer to the SHA-256, SHA-384, and SHA-512 functions defined in SHS. <ins> In addition to the general requirements of ciphersuites, future ciphersuites MUST meet the requirements of confidentiality-of-sender- data. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only include modern, yet well-established