jiebi/TextFlow huggingface dataset:
Original text:
Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition.  Reference: The document where this extension is defined Initial contents:

Reviewer comments:
the "MLS Proposal Types" section defines a table with columns Value Name Recommended Path Required Reference But the template directly above the table only mentions four of the five columns. It does not mention or describe what "Path Required" means. It should probably at least make clear that the field should be either or , and reference section "Commit" where the path requirement is discussed.

Revised text:
Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. <ins> Path Required: Whether a Commit covering a proposal of this type is required to have its "path" field populated (see commit). </ins> Reference: The document where this extension is defined Initial contents:
Original text:
ciphersuite for a credential in a KeyPackage object.  For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using ECDSA <del> with the NIST curves P-256 or P-521, the public key is the output of the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. </del>  For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the

Reviewer comments:
The following statement is no longer up-to-date, given addition of P-384: "For ciphersuites using ECDSA with the NIST curves P-256 or P-521, the public key is..." To avoid tracking too many changes in the future for the document, I suggest the simple edit: "For ciphersuites using ECDSA with the NIST curves, the public key is..."

Revised text:
ciphersuite for a credential in a KeyPackage object.  For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using ECDSA  <ins> with the NIST curves (P-256, P-384, or P-521), the public key is the output of the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. </ins> For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the
Original text:
To enforce forward secrecy and post-compromise security of messages, each participant periodically updates its leaf secret which represents its contribution to the group secret.  Any member of the <del> group can send an Update at any time by generating fresh leaf secret and keys and send an Update message that describes how to update the </del>  group secret with that new information.  Once all participants have processed this message, the group's secrets will be unknown to an attacker that had compromised the sender's prior leaf secret. _siblings_ if they share the same parent. A _subtree_ of a tree is the tree given by the descendants of any <del> 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_). The _direct path_ of a root is the empty list, and of any other node is the concatenation of that node with the direct path of its parent. The _copath_ of a node is the list of siblings of nodes in its direct <del> path, excluding the root, which has no sibling.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. </del>  For example, in the below tree:

Reviewer comments:
NAME Hi Brendan ! Would you mind please revert the last of the 3 changes. Even though the sentence is not amazing and your change correct, I find it better to keep explicit the fact that the root should not be included, instead of having to infer it from the fact it has no siblings :) Thanks !
You don't have to infer it -- direct paths are defined to never include the root node in the sentence just before.

Revised text:
To enforce forward secrecy and post-compromise security of messages, each participant periodically updates its leaf secret which represents its contribution to the group secret.  Any member of the  <ins> group can send an Update at any time by generating a fresh leaf secret and sending an Update message that describes how to update the </ins> group secret with that new information.  Once all participants have processed this message, the group's secrets will be unknown to an attacker that had compromised the sender's prior leaf secret. _siblings_ if they share the same parent. A _subtree_ of a tree is the tree given by the descendants of any  <ins> node, the _head_ of the subtree.  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_). The _direct path_ of a root is the empty list, and of any other node is the concatenation of that node with the direct path of its parent. The _copath_ of a node is the list of siblings of nodes in its direct  <ins> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. </ins> For example, in the below tree:
Original text:
RFC EDITOR PLEASE DELETE THIS SECTION.  draft-13 TLS syntax updates (including variable-header-length vectors) (*)

Reviewer comments:
This should have been done before publishing draft-14, but we can't fix that now. At least this will capture the history in draft-15.
Merging my own PR because this is strictly editorial.

Revised text:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-14 Ensure that a signature public key is always intelligible (*) Clean up terminology of derived secrets/keys Fix parent hash (*) Specify compatibility behavior around new credentials Add Path Required to Proposal Type template Sub-group branching requires fresh key packages for each member Use "aasvg" and typed code blocks Require init key and leaf key to be different Preconfigured senders extension and removal of signature key indirection </ins> draft-13 TLS syntax updates (including variable-header-length vectors) (*)
Original text:
8.4. <del> In order to provide forward secrecy and post-compromise security, whenever a member initiates an epoch change (i.e., commits; see commit), they refresh the key pairs of their leaf and of all nodes on their leaf's direct path (all nodes for which they know the secret key). </del>  The member initiating the epoch change generates the fresh key pairs using the following procedure.  The procedure is designed in a way group are identified by a "external" or "new_member" SenderType in MLSPlaintext. <del> ReInit proposals can also be sent to the group by a "external" </del>  sender, for example to enforce a changed policy regarding MLS version or ciphersuite.

Reviewer comments:
In first paragraph, the "Ratchet Tree Evolution" Section states that whenever a member initiates an epoch change, they refresh the key pair in their leaves, etc. This is not the case for partial commits, where the epoch is advanced without a key update and without achieving PCS.

Revised text:
8.4.  <ins> Whenever a member initiates an epoch change (i.e., commits; see commit), they may need to refresh the key pairs of their leaf and of the nodes on their leaf's direct path in order to maintain forward secrecy and post-compromise security. </ins> The member initiating the epoch change generates the fresh key pairs using the following procedure.  The procedure is designed in a way group are identified by a "external" or "new_member" SenderType in MLSPlaintext.  <ins> ReInit proposals can also be sent to the group by an "external" </ins> sender, for example to enforce a changed policy regarding MLS version or ciphersuite.
Original text:
13.1.8.1. The "external_senders" extension is a group context extension that <del> contains credentials of senders that are permitted to send external proposals to the group. </del>  13.2.

Reviewer comments:
The External Senders Extension allows clients to agree on the entities that are allowed to send external proposals, as well as the signature public keys required to verify them. It contains a list of credentials that is meant to achieve this goal. However, due to a recent change, Credentials don't necessarily contain signature public keys anymore. NAME suggested to have it contain a signature public key, as well as a corresponding Credential, which allows members to verify the binding between signature public key and the owning entity's identity, which I think would be a good solution.
Thanks NAME I like that this captures both the signature and authentication aspects. NAME wdyt?Looks good to me! NAME idea might be a good additional improvement.

Revised text:
13.1.8.1. The "external_senders" extension is a group context extension that  <ins> contains the credentials and signature keys of senders that are permitted to send external proposals to the group. </ins> 13.2.
Original text:
key that can be used to encrypt to that client, and which other clients can use to introduce the client to a new group.  A signing key pair used to authenticate the sender of a message. An MLSPlaintext or MLSCiphertext message carrying an MLS Proposal

Reviewer comments:
There are several references to GroupContext in the first few sections. The details are fine where they are, but it would be good to introduce the notion that GroupContext summarizes the state of the group.

Revised text:
key that can be used to encrypt to that client, and which other clients can use to introduce the client to a new group. <ins> An object that summarizes the state of the group.  The group context is signed to bind a message to a particular group, and also provided to new members to help them join a group. </ins> A signing key pair used to authenticate the sender of a message. An MLSPlaintext or MLSCiphertext message carrying an MLS Proposal
Original text:
16.2. During each epoch senders MUST NOT encrypt more data than permitted <del> by the security bounds of the AEAD scheme used. </del>  Note that each change to the Group through a Handshake message will also set a new "encryption_secret".  Hence this change MUST be

Reviewer comments:
In the "Restrictions" section, we say "During each epoch senders MUST NOT encrypt more data than permitted by the security bounds of the AEAD scheme used", without specifying the limits. We should cite something here, probably (cc NAME for visibility).

Revised text:
16.2. During each epoch senders MUST NOT encrypt more data than permitted  <ins> by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead- limits. </ins> Note that each change to the Group through a Handshake message will also set a new "encryption_secret".  Hence this change MUST be
Original text:
those devices' clients could all present the user's application-layer identifiers. <del> If needed, applications may add application-specific unique identifiers to the "extensions" field of KeyPackage or LeafNode objects. </del>  7. Verify that the value of "leaf_node.encryption_key" is different from the value of the "init_key" field. <del> 11.2. Within MLS, a KeyPackage is identified by its hash (see, e.g., joining-via-welcome-message).  The "external_key_id" extension allows applications to add an explicit, application-defined identifier to a KeyPackage. </del> 12. A group is always created with a single member, the "creator".  The

Reviewer comments:
At first I was going to make an extension for both KeyPackages and LeafNodes. But I was thinking and couldn't come up with a reason for KeyPackages to need this extension, so did just LeafNode.
Interim 2022-05-26: Agreement to merge is getting used a lot, so maybe or ? NAME to change to
What's the use case for this?
Mentioned at the last interim, but the use-case for this feature is either: giving applications an easier way to lookup the private key corresponding to their LeafNode giving applications a place to put client UUIDs

Revised text:
those devices' clients could all present the user's application-layer identifiers.  <ins> If needed, applications may add application-specific identifiers to the "extensions" field of a LeafNode object with the "application_id" extension. However, applications SHOULD NOT rely on the data in an "application_id" extension as if it were authenticated by the Authentication Service, and SHOULD gracefully handle cases where the identifier presented is not unique. </ins> 7. Verify that the value of "leaf_node.encryption_key" is different from the value of the "init_key" field.  12. A group is always created with a single member, the "creator".  The
Original text:
An Add proposal requests that a client with a specified KeyPackage be added to the group. <del> An Add proposal is invalid if any of the following is true: The KeyPackage is invalid according to keypackage-validation. The Credential in the KeyPackage represents a client already in the group according to the application. </del>  An Add is applied after being included in a Commit message.  The position of the Add in the list of proposals determines the leaf node It contains multiple Add proposals that contain KeyPackages that represent the same client according to the application (for <del> example, identical KeyPackages or KeyPackages sharing the same Credential). </del>  It contains multiple PreSharedKey proposals that reference the same PreSharedKeyID.

Reviewer comments:
In , it was pointed out that we previously had a clause: But this was amplified in to say that we also can't send Add proposals for users that are already in the group. I think we should talk about if this is the actual desired behavior or not.
I agree with Brendan. Specifically I want to make sure an MLS client can replace itself. My other concern is that because we have no guidance yet on identity, we need to make sure that multiple instances/clients of the same user are allowed.
Interim 2022-05-26: We want to: Avoid having multiple appearances of the same device Allow a device to resync itself Text at issue here is "An Add proposal is invalid if ... The Credential in the KeyPackage represents a client already in the group according to the application" It sounds like changing to "... The KeyPackage represents a client already in the group according to the application" would address the immediate concern NAME to write a PR

Revised text:
An Add proposal requests that a client with a specified KeyPackage be added to the group.  <ins> An Add proposal is invalid if the KeyPackage is invalid according to keypackage-validation. </ins> An Add is applied after being included in a Commit message.  The position of the Add in the list of proposals determines the leaf node It contains multiple Add proposals that contain KeyPackages that represent the same client according to the application (for  <ins> example, identical signature keys). It contains an Add proposal with a KeyPackage that represents a client already in the group according to the application, unless there is a Remove proposal in the list removing the matching client from the group. </ins> It contains multiple PreSharedKey proposals that reference the same PreSharedKeyID.
Original text:
In this tree, we can see all of the above rules in play: <del> The resolution of node Z is the list [Z, C] </del>  <del> The resolution of leaf 1 is the empty list [] </del>  <del> The resolution of top node is the list [A, Z, C] </del>  5.1.2.

Reviewer comments:
The current resolution example tree can't be created by the protocol. If C were not blank, then D would not populate Z in its filtered direct path. (Note that this implies that there are never unmerged leaves at the first level of the tree.) This PR expands the example tree so that it can have unmerged leaves while still having a blank top node. This makes the example a little more complicated (you have to follow the recursion down two levels), but it doesn't seem too bad.
cc NAME
Good catch! It's kind of subtle in this case.
NAME - I think I have this patched up, would appreciate a quick re-review.
I walked through the example tree on a whiteboard with different colored markers and it looks correct to me.

Revised text:
In this tree, we can see all of the above rules in play:  <ins> The resolution of node X is the list [X, B] </ins>  <ins> The resolution of leaf 2 or leaf 6 is the empty list [] </ins>  <ins> The resolution of top node is the list [X, B, Y, H] </ins> 5.1.2.
Original text:
The fields in this state have the following semantics:  The "group_id" field is an application-defined identifier for the group. steps: Verify that the ciphersuite and protocol version of the KeyPackage <del> match those in use in the group. </del>  Verify that the "leaf_node" of the KeyPackage is valid for a KeyPackage according to leaf-node-validation. the external init secret as described in external-initialization. The sender type for the MLSAuthenticatedContent encapsulating the <del> External Commit MUST be "new_member_commit " </del>  External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's Verify that the "group_id" is unique among the groups that the client is currently participating in.  Verify the integrity of the ratchet tree. Verify that the tree hash of the ratchet tree matches the

Reviewer comments:
This will guarantee that all group members agree on the ciphersuite used. It gives more meaning to statements like "Each MLS session uses a single ciphersuite". Also, it prevents the following attack: the adversary (a malicious insider) invites someone and convinces them that the group uses a ciphersuite with say a signature scheme that is weaker but still compatible with the one actually used. Now the new member uses a weaker scheme and the adversary can impersonate them.
Interim 2022-06-02: Agreement that more binding is better

Revised text:
The fields in this state have the following semantics: <ins> The "cipher_suite" is the cipher suite used by the group. </ins> The "group_id" field is an application-defined identifier for the group. steps: Verify that the ciphersuite and protocol version of the KeyPackage  <ins> match those in the "GroupContext". </ins> Verify that the "leaf_node" of the KeyPackage is valid for a KeyPackage according to leaf-node-validation. the external init secret as described in external-initialization. The sender type for the MLSAuthenticatedContent encapsulating the  <ins> External Commit MUST be "new_member_commit". </ins> External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's Verify that the "group_id" is unique among the groups that the client is currently participating in. <ins> Verify that the "cipher_suite" in the GroupInfo matches the "cipher_suite" in the KeyPackage. </ins> Verify the integrity of the ratchet tree. Verify that the tree hash of the ratchet tree matches the
Original text:
RFC EDITOR PLEASE DELETE THIS SECTION.  draft-14 Ensure that a signature public key is always intelligible (*)

Reviewer comments:
Constructed from the highlights of PR titles, with breaking changes indicated with as usual.
Just filing this so that I don't forget it before posting the draft.
Fixed by

Revised text:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-15 Include ciphersuite in group context (*) Add new new_proposal_member SenderType (*) Always use a full tree (*) Change KeyPackage identifier extension to be LeafNode identifier (*) Use new tree for context in path secret encryption (*) Use a hash function for hash identifiers (*) Add a marker byte to tree hash input structs (*) Recommend that group ids are generated randomly (*) Update external senders extension to have SignaturePublicKey and Credential (*) Replace LeafNodeRef with leaf index (*) Remove AppAck proposal (*) Make padding arbitrary-size and all-zero (*) Require that unmerged_leaves be ordered Derive the commit secret from the end of the UpdatePath, not the root Specify the precise points in the protocol where credential validation must be done Make PSK provisions more uniform, e.g., always generating a fresh random nonce Improve parent hash guarantees with stricter checks on tree correctness Streamline some structs, e.g., folding GroupContext into GroupInfo Provide clearer rules for validating and applying commits Clarify tree hash and parent hash, and correct examples Clean up struct names and references to outdated structs Cite AEAD limits draft </ins> draft-14 Ensure that a signature public key is always intelligible (*)
Original text:
The "epoch" field increments by one for each GroupOperation that is processed <del> The "transcript" is updated by a GroupOperation message "operation" by appending "operation" to "transcript" </del>  5.6.

Reviewer comments:
There is no reason for the members of a conversation to keep the whole history of group operations, but they should agree on it.

Revised text:
The "epoch" field increments by one for each GroupOperation that is processed  <ins> The "transcript_hash" is updated by a GroupOperation message "operation" in the following way: When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero vector of length Hash.length. </ins> 5.6.
Original text:
over arbitrary lower layer protocols.  The security considerations in this document (RFC XXXX) also apply.  18.  References 18.1.  URIs [1] mailto:mls-reg-review@ietf.org [2] mailto:iesg@ietf.org 

Reviewer comments:
Early review from IANA indicated that we had not completed the . This PR adds the missing fields.

Revised text:
over arbitrary lower layer protocols.  The security considerations in this document (RFC XXXX) also apply. <ins> N/A RFC XXXX MLS-based messaging applications N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A IETF MLS Working Group mls@ietf.org [3] COMMON N/A IETF MLS Working Group IESG No </ins> 18.  References 18.1.  URIs [1] mailto:mls-reg-review@ietf.org [2] mailto:iesg@ietf.org <ins> [3] mailto:mls@ietf.org </ins>
Original text:
A member of the group applies a Remove message by taking the following steps: <del> Identify a leaf node matching "removed".  This lookup MUST be done on the tree before any non-Remove proposals have been applied (the "old" tree in the terminology of commit), since proposals such as Update can change the LeafNode stored at a leaf.  Let L be this leaf node. </del>  Replace the leaf node L with a blank node

Reviewer comments:
The part about doing the lookup in the old tree was added in , it was relevant here because of the hash references. This is not a problem anymore since we came back to referencing with leaf index.

Revised text:
A member of the group applies a Remove message by taking the following steps:  <ins> Identify the leaf node matching "removed".  Let L be this leaf node. </ins> Replace the leaf node L with a blank node
Original text:
external public key In other words, to join a group via an External Commit, a new member <del> needs a GroupInfo with an "ExternalPub" extension present in its </del>  "extensions" field. Thus, a member of the group can enable new clients to join by making

Reviewer comments:
For consistency with references to other extensions (and with the IANA registry), refer to the extension as "external_pub".

Revised text:
external public key In other words, to join a group via an External Commit, a new member  <ins> needs a GroupInfo with an "external_pub" extension present in its </ins> "extensions" field. Thus, a member of the group can enable new clients to join by making