jiebi/TextFlow huggingface dataset:
Original text:
client being added to new groups by exhausting all available InitKeys.  16. This document requests the creation of the following new IANA

Reviewer comments:
In preparation for feature-freeze / post-first-WGLC living, this PR removes a few issues that have been discussed and pretty much resolved. It leaves a few OPEN ISSUES that could benefit from analysis during the feature freeze.

Revised text:
client being added to new groups by exhausting all available InitKeys. <ins> 15.5. It is possible for a malicious member of a group to "fragment" the group by crafting an invalid UpdatePath.  Recall that an UpdatePath encrypts a sequence of path secrets to different subtrees of the group's ratchet trees.  These path secrets should be derived in a sequence as described in ratchet-tree-evolution, but the UpdatePath syntax allows the sender to encrypt arbitrary, unrelated secrets. The syntax also does not guarantee that the encrypted path secret encrypted for a given node corresponds to the public key provided for that node. Both of these types of corruption will cause processing of a Commit to fail for some members of the group.  If the public key for a node does not match the path secret, then the members that decrypt that path secret will reject the commit based on this mismatch.  If the path secret sequence is incorrect at some point, then members that can decrypt nodes before that point will compute a different public key for the mismatched node than the one in the UpdatePath, which also causes the Commit to fail.  Applications SHOULD provide mechanisms for failed commits to be reported, so that group members who were not able to recognize the error themselves can reject the commit and roll back to a previous state if necessary. Even with such an error reporting mechanism in place, however, it is still possible for members to get locked out of the group by a malformed commit.  Since malformed Commits can only be recognized by certain members of the group, in an asynchronous application, it may be the case that all members that could detect a fault in a Commit are offline.  In such a case, the Commit will be accepted by the group, and the resulting state possibly used as the basis for further Commits.  When the affected members come back online, they will reject the first commit, and thus be unable to catch up with the group. Applications can address this risk by requiring certain members of the group to acknowledge successful processing of a Commit before the group regards the Commit as accepted.  The minimum set of acknowledgements necessary to verify that a Commit is well-formed comprises an acknowledgement from one member per node in the UpdatePath, that is, one member from each subtree rooted in the copath node corresponding to the node in the UpdatePath. </ins> 16. This document requests the creation of the following new IANA
Original text:
committer's contribution to the group and provides PCS with regard to the committer. <del> An "add-only" Commit that references only Add proposals, in which the path is optional.  Such a commit provides PCS with regard to the committer only if the path field is present. </del>  A "full" Commit that references proposals of any type, which provides FS with regard to any removed members and PCS for the

Reviewer comments:
Discussed at 20210526 Interim. Merge.
Good point about allowing PSKs in a partial Commit!

Revised text:
committer's contribution to the group and provides PCS with regard to the committer.  <ins> A "partial" Commit that references Add, PreSharedKey, or ReInit proposals but where the path is empty.  Such a commit doesn't provide PCS with regard to the committer. </ins> A "full" Commit that references proposals of any type, which provides FS with regard to any removed members and PCS for the
Original text:
A signature algorithm <del> MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key </del>  encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs.

Reviewer comments:
draft-08 is the latest HPKE draft, which should be stable. It is also what's being used for interop testing right now.
Discussed 20210526 Interim: Merge.

Revised text:
A signature algorithm  <ins> MLS uses draft-08 of HPKE I-D.irtf-cfrg-hpke for public-key </ins> encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs.
Original text:
DeriveSecret takes its Secret argument from the incoming arrow  When processing a handshake message, a client combines the following information to derive new epoch secrets:

Reviewer comments:
Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".

Revised text:
DeriveSecret takes its Secret argument from the incoming arrow <ins> "0" represents an all-zero byte string of length "KDF.Nh". </ins> When processing a handshake message, a client combines the following information to derive new epoch secrets:
Original text:
in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: <del> Here "0" represents the all-zero vector of length KDF.Nh.  The </del>  "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract

Reviewer comments:
Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".

Revised text:
in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows:  <ins> Here "0" represents the all-zero vector of length "KDF.Nh".  The </ins> "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract
Original text:
If not populating the "path" field: Set the "path" field in the Commit to the null optional.  Define "commit_secret" as the all- <del> zero vector of the same length as a "path_secret" value would be. In this case, the new ratchet tree is the same as the provisional ratchet tree. </del>  Derive the "psk_secret" as specified in pre-shared-keys, where the order of PSKs in the derivation corresponds to the order of

Reviewer comments:
Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".

Revised text:
If not populating the "path" field: Set the "path" field in the Commit to the null optional.  Define "commit_secret" as the all-  <ins> zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be).  In this case, the new ratchet tree is the same as the provisional ratchet tree. </ins> Derive the "psk_secret" as specified in pre-shared-keys, where the order of PSKs in the derivation corresponds to the order of
Original text:
from the "path_secret[n]" value assigned to the root node. If the "path" value is not populated: Define "commit_secret" as <del> the all-zero vector of the same length as a "path_secret" value would be. </del>  Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext.

Reviewer comments:
Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".

Revised text:
from the "path_secret[n]" value assigned to the root node. If the "path" value is not populated: Define "commit_secret" as  <ins> the all-zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be). </ins> Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext.
Original text:
process the Commit (i.e., not including any members being added or removed by the Commit).  If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove

Reviewer comments:
Any Update proposal for the sender is redundant if the Commit includes a .
This is true, but they're also harmless, since the information in the will overwrite all of their effects. Note that: A requirement to this effect would only be binding on a committer. The receiver of a Commit MUST process all of the referenced proposals, as prescribed in the Commit. A is required if a Commit covers Updates or Removes; if a Commit covers a self-Update, then it must have a . So there's no reasn to condition on "if a is included". This seems fine for some advisory text, but not an absolute prohibition.
The way I read Section 11.2 is that the receiver should verify that the committer has followed the rules, e.g. that the commit contains all valid proposals, etc., even if that is not explicit in the list of things the receiver of a commit should do. So any requirement on the committer would also affect the receiver. So if we mandate that a committer can't include self-updates if the path is populated, then it would be implicit that the receiver checks that the committer actually followed the rules when processing a commit. I'm not sure I understand your second point. My reasoning would be that if a committer wants to do an update, they would just include a path rather than an update proposal, which is redundant anyway.
Sorry NAME I missed that there was still conversation going on here before merging . On the latter point: All I'm saying is that there is no case where there is both (a) a self-update and (b) no . So you're always in the bad scenario :) In our Wire chat, you made a good point that repeated proposals for the same leaf are invalid, and self-Updates are effectively repeats of the . Reopening, will file a fresh PR to adjust the text.

Revised text:
process the Commit (i.e., not including any members being added or removed by the Commit). <ins> The sender of a Commit SHOULD NOT include any Update proposals that the sender themselves generated.  If sender generated one or more Update proposals during an epoch, then it SHOULD instead update its leaf and direct path by sending "path" field in the Commit. </ins> If there are multiple proposals that apply to the same leaf, the committer chooses one and includes only that one in the Commit, considering the rest invalid.  The committer MUST prefer any Remove
Original text:
actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism.  5. The protocol uses "ratchet trees" for deriving shared secrets among a

Reviewer comments:
Adds the overview text proposed in .
Thanks NAME !
Thanks for putting together the overview. The figures are great :-) Looks good to me with one proposition.

Revised text:
actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism. <ins> 4.3. A group comprises a single linear sequence of epochs and groups are generally independent of one-another.  However, it can sometimes be useful to link epochs cryptographically, either within a group or across groups.  MLS derives a resumption pre-shared key (PSK) from each epoch to allow entropy extracted from one epoch to be injected into a future epoch.  This link guarantees that members entering the new epoch agree on a key if and only if were members of the group during the epoch from which the resumption key was extracted. MLS supports two ways to tie a new group to an existing group.  Re- initialization closes one group and creates a new group comprising the same members with different parameters.  Branching starts a new group with a subset of the original group's participants (with no effect on the original group).  In both cases, the new group is linked to the old group via a resumption PSK. Applications may also choose to use resumption PSKs to link epochs in other ways.  For example, the following figure shows a case where a resumption PSK from epoch "n" is injected into epoch "n+k".  This demonstrates that the members of the group at epoch "n+k" were also members at epoch "n", irrespective of any changes to these members' keys due to Updates or Commits. </ins> 5. The protocol uses "ratchet trees" for deriving shared secrets among a
Original text:
precisely two children, a _left_ child and a _right_ child.  A node is the _root_ of a tree if it has no parents, and _intermediate_ if it has both children and parents.  The _descendants_ of a node are <del> that node, its children, and the descendants of its children, and we say a tree _contains_ a node if that node is a descendant of the root of the tree.  Nodes are _siblings_ if they share the same parent. </del>  <del> A _subtree_ of a tree is the tree given by the descendants of any node, the _head_ of the subtree.  The _size_ of a tree or subtree is </del>  the number of leaf nodes it contains.  For a given parent node, its _left subtree_ is the subtree with its left child as head (respectively _right subtree_).

Reviewer comments:
Make the definition of descendant match the common-sense definition (you are not your own descendant), adjust the text which uses the definition. Note: this allows for a much clearer definition of the tree invariant as well.

Revised text:
precisely two children, a _left_ child and a _right_ child.  A node is the _root_ of a tree if it has no parents, and _intermediate_ if it has both children and parents.  The _descendants_ of a node are  <ins> that node's children, and the descendants of its children, and we say a tree _contains_ a node if that node is a descendant of the root of the tree, or if the node itself is the root of the tree.  Nodes are _siblings_ if they share the same parent. </ins>  <ins> A _subtree_ of a tree is the tree given by any node (the _head_ of the subtree) and its descendants.  The _size_ of a tree or subtree is </ins> the number of leaf nodes it contains.  For a given parent node, its _left subtree_ is the subtree with its left child as head (respectively _right subtree_).
Original text:
be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs.  19.  References 19.1.  URIs

Reviewer comments:
This is a minimal section for MIME type registration of message/mls. It assumes that PR include wire_format in all MLS messages (making a format parameter unnecessary), and that all messages have the MLS version number encoded (making a version parameter unnecessary). These parameters can be added if needed.
When MLS messages are transmitted over a protocol which supports Content-Type / MIME Type negotiation, signal that the message is an MLS message. Because MLS messages are really a bag of formats today we should have a MIME type parameter which specifies the specific format included. message/mls;format={applicationgroupcontext}
This seems like a fine idea to me. Could go as a section in the protocol spec, or as a separate (small) spec.
Discussion on virtual interim: Section or separate doc? How do we handle versioning? Internal to the protocol (field in MLSMessage?) Field in the MIME type Different MIME type per version
I would prefer a short section in the protocol document. I think Internal to the protocol is cleanest. Likewise the format parameter becomes unnecessary if we add Welcome, PublicGroupState, and KeyPackage to wire_format (see issue )
NAME send a PR?
Asking for friend: would we want to define (or use) a structured syntax suffix ala ?
NAME If you mean for multiple formats, no, we have only one encoding. If someone wants to re-encode the protocol as XML or whatever, a MIME type will be the least of their troubles.
Fixed in

Revised text:
be perceived as creating a conflict of interest for a particular MLS DE, that MLS DE SHOULD defer to the judgment of the other MLS DEs. <ins> 18.6. This document registers the "message/mls" MIME media type in order to allow other protocols (ex: HTTP RFC7540) to convey MLS messages. </ins> 19.  References 19.1.  URIs
Original text:
The tree hash of a tree is the tree hash of its root node, which we define recursively, starting with the leaves. <del> As some nodes may be blank while others contain data we use the following struct to include data if present. </del> The tree hash of a leaf node is the hash of leaf's "LeafNodeHashInput" object which might include a "LeafNode" object depending on whether or not it is blank.

Reviewer comments:
There are two changes in this PR: Pull the extension to the TLS syntax up into the Terminology section Add an extension that lets vectors have variable-length headers, allowing them to be efficient at small sizes while also accommodating large sizes All vectors are converted to the variable-length header representation. It seems like this should simplify implementation, since the encoder will no longer have to be told how many bytes of header to use for a given vector. This has been the source of several annoying interop bugs.
Looks great! I only have a small objection: there is now several valid ways to serialize a length, as the example shows, both and are valid ways to encode 37. This means that if you parse a structure, and later want to re-serialize it to check a signature for example, you need to remember how many bits were used to store the length. In short, we loose the property that . The fix is easy: can we add that "the length MUST be stored using the smallest amount of bits possible"?
Good point, updated!
I wasn't clear under which circumstances you would use a longer length with a number that would fit in a smaller range. If never, then the table should be:
DIscussion on virtual interim Some concern about being able to send gigantic stuff In adversarial cases, the 4-byte headers used for a lot of stuff might already be a problem Could also have length constraints decoupled from the syntax SIP experience shows that imposing arbitrary length limits isn't a good idea ... but applications should have a way to signal that things are too big TODO(NAME Advisory text "Beware, things can get big; consider imposing limits and clear failure cases for this" Consider streaming implementations, where you might not know that the whole message fits in memory Modulo the above TODO, clear to merge

Revised text:
The tree hash of a tree is the tree hash of its root node, which we define recursively, starting with the leaves.  The tree hash of a leaf node is the hash of leaf's "LeafNodeHashInput" object which might include a "LeafNode" object depending on whether or not it is blank.
Original text:
A GroupContextExtensions proposal is used to update the list of extensions in the GroupContext for the group. <del> "struct { Extension extensions<0..2^32-1>; } GroupContextExtensions; " </del>  A member of the group applies a GroupContextExtensions proposal with the following steps:

Reviewer comments:
There are two changes in this PR: Pull the extension to the TLS syntax up into the Terminology section Add an extension that lets vectors have variable-length headers, allowing them to be efficient at small sizes while also accommodating large sizes All vectors are converted to the variable-length header representation. It seems like this should simplify implementation, since the encoder will no longer have to be told how many bytes of header to use for a given vector. This has been the source of several annoying interop bugs.
Looks great! I only have a small objection: there is now several valid ways to serialize a length, as the example shows, both and are valid ways to encode 37. This means that if you parse a structure, and later want to re-serialize it to check a signature for example, you need to remember how many bits were used to store the length. In short, we loose the property that . The fix is easy: can we add that "the length MUST be stored using the smallest amount of bits possible"?
Good point, updated!
I wasn't clear under which circumstances you would use a longer length with a number that would fit in a smaller range. If never, then the table should be:
DIscussion on virtual interim Some concern about being able to send gigantic stuff In adversarial cases, the 4-byte headers used for a lot of stuff might already be a problem Could also have length constraints decoupled from the syntax SIP experience shows that imposing arbitrary length limits isn't a good idea ... but applications should have a way to signal that things are too big TODO(NAME Advisory text "Beware, things can get big; consider imposing limits and clear failure cases for this" Consider streaming implementations, where you might not know that the whole message fits in memory Modulo the above TODO, clear to merge

Revised text:
A GroupContextExtensions proposal is used to update the list of extensions in the GroupContext for the group.  <ins> "struct { Extension extensions<V>; } GroupContextExtensions; " </ins> A member of the group applies a GroupContextExtensions proposal with the following steps:
Original text:
Verify that the signature on the KeyPackage is valid using the public key in "leaf_node.credential".  11.2. Within MLS, a KeyPackage is identified by its hash (see, e.g.,

Reviewer comments:
This change ensures that the "init" key pair associated to the key package is one-time-use, at least to the degree that KeyPackages are one-time-use. The init key pair is used to encrypt/decrypt the Welcome message, then never again. The main drawback is requiring the KeyPackage sender to generate an additional key pair, which requires more computation and more entropy.

Revised text:
Verify that the signature on the KeyPackage is valid using the public key in "leaf_node.credential". <ins> Verify that the value of "leaf_node.public_key" is different from the value of the "init_key" field. </ins> 11.2. Within MLS, a KeyPackage is identified by its hash (see, e.g.,