Original text:
9.1. <del> 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. </del>  9.2. The "ciphertext" field of the MLSCiphertext object is produced by supplying the inputs described below to the AEAD function specified <del> by the ciphersuite in use.  The plaintext input contains content and signature of the MLSPlaintext, plus optional padding.  These values are encoded in the following form: </del>  The key and nonce used for the encryption of the message depend on the content type of the message.  The sender chooses the handshake Initial contents: <del> These ciphersuites map to HPKE primitives and TLS signature schemes </del>  as follows I-D.irtf-cfrg-hpke RFC8446: The hash used for the MLS transcript hash is the one referenced in

Reviewer comments:
that MLSPlaintext does not currently authenticate the sender's membership on the group, and as a result, some important attacks arise. Discussion on the list indicated that adding a MAC with a key derived from the key schedule would provide this authentication. This PR implements that suggestion.
Lgtm. Rebase and I'll properly approve.
Generally not a fan of rebasing, but here you go.
From NAME ... This would be a useful terminology to describe a client which shares its cryptographic material across multiple device. To be discussed ?
Done in draft-06 Yeah, I like Option 2 here. I like that it avoids growing packet size. One caveat though: I'd go for the MAC(...) version rather than the confirmationkey. For starters thing including confirmationkey doesnt authenticate the contents of the packet. But even if it did, signatures aren't meant to hide the contents of what was signed. (Amend you favorite sig scheme to tack on the message at the end a signature and you've still got a secure signature scheme. But clearly not a message hiding one.) That means that AFAIK neither ECDSA nor EdDSA etc. were designed or analyzed for such a property. So this would amount to a very non-standard use of a signature schemes by MLS. Not saying it doesn't work for the particular sig schemes in our ciphersuite. But its def. not how signatures are "meant" to be used. But that leaves Option 2 with, say, including tag = MAC(confkey, conftranshash MLSPlaintext.content) into whats being signed which I like and think gets the job done. Both conf* values are taken from the current epoch. By MLSPlaintext.content I mean whats now called MLSPlaintextTBS. NAME For Proopsals I think this works. Is that about what you had in mind for commits too? Joël On 18/08/2020 17:26, Richard Barnes wrote: >

Revised text:
9.1.  <ins> The "signature" field in an MLSPlaintext object authenticates the sender of the MLSPlaintext message.  The input to the signature is an MLSPlaintextTBS structure, which encodes the content and metadata of the message as well a context for the signature that associates to the group messages sent within the group. In cases where the sender is a member of the group, the context contains the GroupContext for the current epoch and a "membership tag" that authenticates that the sender is a member of the group.  As a result, for messages sent within a group, the signature authenticates the member's individual identity, and the membersip tag authenticates their membership in the group. The "membership_tag" field in the MLSPlaintext object authenticates the sender's membership in the group.  For an MLSPlaintext with a sender type other than "member", this field MUST be omitted.  For messages sent by members, it MUST be present and set to the following value: When the sender type is "member", the "membership_tag" field MUST contain a full-size MAC output, and MUST be verified before verifying the signature or processing the message content.  For other sender types, the "membership_tag" field MUST be set to the zero-length octet string. </ins> 9.2. The "ciphertext" field of the MLSCiphertext object is produced by supplying the inputs described below to the AEAD function specified  <ins> by the ciphersuite in use.  The plaintext input contains the content and signature of the MLSPlaintext, plus optional padding.  (The membership token is not included in the encrypted content, because the AEAD operation already authenticates the sender's membership in the group.)  These values are encoded in the following form: Note that the "membership_tag" is not carried forward from MLSPlaintext to MLSCiphertext.  In the context of an MLSCiphertext, the AEAD authentication provides the function that the "membership_tag" provides for MLSPlaintext. </ins> The key and nonce used for the encryption of the message depend on the content type of the message.  The sender chooses the handshake Initial contents:  <ins> All of these ciphersuites use HMAC RFC2104 as their MAC function, with different hashes per ciphersuite.  The mapping of ciphersuites to HPKE primitives, HMAC hash functions, and TLS signature schemes is </ins> as follows I-D.irtf-cfrg-hpke RFC8446: The hash used for the MLS transcript hash is the one referenced in