Draft: draft-ietf-mls-protocol

Commentary: 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 do n't think we need AE2 encryption because our nonces are random and do n'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 do n't have a security proof for any of this . So more eyes on whatever we write here would be appreciated . 
 Comment by I do n't think I understand the security model here ? What happens if the previous ciphertext has 00 's for the first  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 is n'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 can not 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 who did some analysis on this IIRC 
 I did n't do analysis on this , however I 'm a bit concerned by the assertion " due to the ciphertext looking like random data " . I do n'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 . Was n't this inspired by QUIC somehow ( maybe header encryption ) ? In any case , if we do n't do so already , we might want to explicitly note this in the ciphersuite section to ensure that AEAD schemes 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 .
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
In addition to the general requirements of ciphersuites, future
ciphersuites MUST meet the requirements of confidentiality-of-sender-
data.