Change:
URL Reviewer: Rich Salz Review result: Ready with Nits I reviewed this draft for ART. I did not review the cryptography as I am unqualified, compared with the draft authors (and other participants). Overall: I think references should be uppercase, as "[art]" should be "[ART]" Abstract: Nicely describes the problem. Is 'forward secrecy and post-compromise security' redundant? If not, there should be definitions in the draft for both terms and perhaps a forward link toe the terminology section. Introduction. "pairwise broadcast of individual messages" seems to go to far for terseness to make the sentence grammatical. The section on common strategy should have a reference or two to implementations. And do you mean "unilaterally broadcast Asymmetric keys" Or is the common technique to allow everyone to impersonate anyone? Sec 2, Terminology. Alphabetical order please. Maybe mention that MSLPlaintext, MLSCiphertext are message formats described in section 4.1; I wondered why they didn't appear in the terminology. And when I searched forward to find where they are defined, I noticed that elsewhere they are rendered as for example, and here the underscores aren't present. Consistency is a virtue. The last paragraph starts by saying "keys and secrets are used interchangeably" which is contradicted by the last sentence. Sec 2.1.2 I was consistently confused by the term "variable-size vector headers" Suggest replacing "Headers" with "Sizes" The parenthetical should not be parenthesized, the difference is important and not an aside. The example vector should be "StructWithVector" not plural, right? The examples are useful, but should be more clear that they are sample encodings of the length bytes and mark the length of the following vector in bytes. Sec 3. Short and understandable. Sec 4. Not short :) but understandable. Sec 4.2 is very useful and have a nice use of the railroad diagrams. The section title should be plural tho. "Executions" Is there any guidance to be offered on access control policies? How does A know whether or not Z can remove B? Are messages NAK'd or ignored or something else? I guess a forward link to 6.3 makes sense. Sec 5 The worked examples are very useful. I like figure 9 Sec 6.2, nit no underscores around first use of I skimmed sec 7 and 8. The end of 8.4 'where lp and np[i] represent" confused me as I don't see those notations in the diagram that follows. Doing a spot-check of these sections it seems that overall the text is clear. Sorry, I ran out of time do finish the document. Holy cow, this is a large document with a great deal of technical detail. I'll be surprised if you got much early feedback. More time, next time, please. Table 5 says "LVL the security level" Should mention "strengh in bits" maybe.

Discussion:
A group of users who want to send each other encrypted messages needs a way to derive shared symmetric encryption keys.  For two parties, this problem has been studied thoroughly, with the Double Ratchet <del> emerging as a common solution doubleratchet signal.  Channels </del> <ins> emerging as a common solution DoubleRatchet Signal.  Channels </ins> implementing the Double Ratchet enjoy fine-grained forward secrecy as well as post-compromise security, but are nonetheless efficient enough for heavy use over low-bandwidth networks.

For a group of size greater than two, a common strategy is to unilaterally broadcast symmetric "sender" keys over existing shared symmetric channels, and then for each member to send messages to the <del> group encrypted with their own sender key.  Unfortunately, while this improves efficiency over pairwise broadcast of individual messages and provides forward secrecy (with the addition of a hash ratchet), it is difficult to achieve post-compromise security with sender keys. </del> <ins> group encrypted with their own sender key.  On the one hand, using sender keys improves efficiency relative to pairwise broadcast of individual messages, and it provides forward secrecy (with the addition of a hash ratchet).  On the other hand, it is difficult to achieve post-compromise security with sender keys, requiring a number of key update messages that scales as the square of the group size. </ins> An adversary who learns a sender key can often indefinitely and passively eavesdrop on that member's messages.  Generating and distributing a new sender key provides a form of post-compromise

In this document, we describe a protocol based on tree structures that enable asynchronous group keying with forward secrecy and post- compromise security.  Based on earlier work on "asynchronous <del> ratcheting trees" art, the protocol presented here uses an </del> <ins> ratcheting trees" ART, the protocol presented here uses an </ins> asynchronous key-encapsulation mechanism for tree structures.  This mechanism allows the members of the group to derive and update shared keys with costs that scale as the log of the group size.

further secret values, and "key" to refer to a value that is used with an algorithm such as HMAC or an AEAD algorithm. <ins> The MLSPlaintext and MLSCiphertext formats are defined in message- framing; they represent integrity-protected and confidentiality- protected messages, respectively.  Security notions such as forward secrecy and post-compromise security are defined in security- considerations. </ins> 2.1. We use the TLS presentation language RFC8446 to describe the

In MLS, there are several vectors whose sizes vary over significant ranges.  So instead of using a fixed-size length field, we use a variable-size length using a variable-length integer encoding based <del> on the one in Section 16 of RFC9000.  (They differ only in that the one here requires a minimum-size encoding.)  Instead of presenting min and max values, the vector description simply includes a "V". For example: </del> <ins> on the one in Section 16 of RFC9000.  They differ only in that the one here requires a minimum-size encoding.  Instead of presenting min and max values, the vector description simply includes a "V".  For example: </ins> Such a vector can represent values with length from 0 bytes to 2^30 bytes.  The variable-length integer encoding reserves the two most

Vectors that start with "11" prefix are invalid and MUST be rejected. <del> For example, the four byte sequence 0x9d7f3e7d decodes to 494878333; the two byte sequence 0x7bbd decodes to 15293; and the single byte 0x25 decodes to 37. </del> <ins> For example: The four byte length value 0x9d7f3e7d decodes to 494878333. The two byte length value 0x7bbd decodes to 15293. The single byte length value 0x25 decodes to 37. </ins> The following figure adapts the pseudocode provided in RFC9000 to add a check for minimum-length encoding:

secrets: After applying the UpdatePath, the tree will have the following <del> structure, where "lp" and "np[i]" represent the leaf_priv and node_priv values generated as described above: </del> <ins> structure: </ins> 8.5.

16.3. <ins> Forward secrecy and post-compromise security are important security notions for long-lived MLS groups.  Forward secrecy means that messages sent at a certain point in time are secure in the face of later compromise of a group member.  Post-compromise security means that messages are secure even if a group member was compromised at some point in the past. </ins> Post-compromise security is provided between epochs by members regularly updating their leaf key in the ratchet tree.  Updating their leaf key prevents group secrets from continuing to be encrypted to previously compromised public keys. <del> Forward-secrecy between epochs is provided by deleting private keys </del> <ins> Forward secrecy between epochs is provided by deleting private keys </ins> from past versions of the ratchet tree, as this prevents old group secrets from being re-derived.  Forward secrecy _within_ an epoch is provided by deleting message encryption keys once they've been used