Draft: draft-ietf-mls-protocol

Commentary: Just to recap the options as I understand them : a ) Today : encryptedsenderdata = AEAD(senderdatakey , senderdatanonce , ( groupID , epoch ) , senderdata ) encryptedcontent =   , appkey[i][j ] , ( groupID , epoch , encryptedsenderdata ) , content ) b ) Sample sender data nonce from ciphertext ( saves explicit nonce ) encryptedcontent =   , appnonce[i][j ] , ( groupID , epoch ) , content ) encryptedsenderdata = AEAD(senderdatakey , sample(encryptedcontent ) , ( groupID , epoch , encryptedcontent ) , senderdata ) c )  auth tag from content encryption ( saves explicit nonce and content auth tag ) encryptedcontent = Enc(appkey[i][j ] , appnonce[i][j ] , content ) encryptedsenderdata = AEAD(senderdatakey , sample(encryptedcontent ) , ( groupID , epoch , encryptedcontent ) , senderdata ) 
 Earlier , we had considered a " masking " approach for sender data , much like QUIC does for . This approach would save 28 bytes of overhead ( nonce + tag ) , but was abandoned because of uncertainty around the security of the masking approach . Since then , Bellare et al . published , which includes what is effectively a proof of the security properties of the QUIC scheme . The QUIC scheme is essentially scheme HN1 of the paper , the main difference being that QUIC encrypt not the nonce directly , but a packet number which is used to compute the nonce . Our application would be similar , since we would encrypt metadata used to encrypt the key and the nonce . Given this new analysis , is it time to bring back masking ? 
 Fixed by
Paragraph (version B):
The sender information used to look up the key for content encryption
is encrypted with an AEAD where the key and nonce are derived from
both "sender_data_secret" and a sample of the encrypted message
content.
Paragraph (version A):
Keys, nonces and secrets of ratchets are derived using
DeriveAppSecret.  The context in a given call consists of the index
of the sender's leaf in the ratchet tree and the current position in
the ratchet.  In particular, the index of the sender's leaf in the
ratchet tree is the same as the index of the leaf in the AS Tree used
to initialize the sender's ratchet.
Paragraph (version B):
Keys, nonces, and the secrets in ratchets are derived using
DeriveAppSecret.  The context in a given call consists of the index
of the sender's leaf in the ratchet tree and the current position in
the ratchet.  In particular, the index of the sender's leaf in the
ratchet tree is the same as the index of the leaf in the AS Tree used
to initialize the sender's ratchet.
Paragraph (version A):
Decryption is done by decrypting the metadata, then the message, and
then verifying the content signature.
Paragraph (version A):
The "reuse_guard" field contains a fresh random value used to avoid
nonce reuse in the case of state loss or corruption, as described in
content-signing-and-encryption.
Paragraph (version A):
The signature field in an MLSPlaintext object is computed using the
signing private key corresponding to the credential at the leaf in
the tree indicated by the sender field.  The signature covers the
plaintext metadata and message content, which is all of MLSPlaintext
except for the "signature" field.  The signature also covers the
GroupContext for the current epoch, so that signatures are specific
to a given group and epoch.
Paragraph (version B):
Encrypt the sender data using a key and nonce derived from the
"sender_data_secret" for the epoch and a sample of the encrypted
MLSCiphertextContent.
Paragraph (version B):
Decryption is done by decrypting the sender data, then the message,
and then verifying the content signature.
Paragraph (version B):
The "signature" field in an MLSPlaintext object is computed using the
signing private key corresponding to the credential at the leaf in
the tree indicated by the sender field.  The signature covers the
plaintext metadata and message content, which is all of MLSPlaintext
except for the "signature" field.  The signature also covers the
GroupContext for the current epoch, so that signatures are specific
to a given group and epoch.
Paragraph (version A):
The ciphertext field of the MLSCiphertext object is produced by
supplying these inputs to the AEAD function specified by the
ciphersuite in use.
Paragraph (version B):
The "reuse_guard" field contains a fresh random value used to avoid
nonce reuse in the case of state loss or corruption, as described in
content-encryption.
Paragraph (version A):
The mandatory-to-implement ciphersuite for MLS 1.0 is
"MLS10\_128\_HPKE25519\_AES128GCM\_SHA256\_Ed25519" which uses
Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE, and AES-
128-GCM with Ed25519 for symmetric encryption and signatures.
Paragraph (version B):
The mandatory-to-implement ciphersuite for MLS 1.0 is
"MLS10\_128\_HPKE25519\_AES128GCM\_SHA256\_Ed25519" which uses
Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over
SHA2-256, AES for metadata masking, and Ed25519 for signatures.