jiebi/CodeConvo huggingface dataset:
Change:
While reviewing , I noticed that in one place, we define the initial to be the all-zero vector, and in another, we define it to be the empty octet string. In keeping with the idea of starting chained hashes with the empty octet string, this PR normalizes on the empty octet string for the transcript hashes as well.

Discussion:
that the chosen version and ciphersuite is the best option supported by all members. <del> Initialize a one-member group with the following initial values (where "0" represents an all-zero vector of size KDF.Nh): </del> <ins> Initialize a one-member group with the following initial values: </ins> Ratchet tree: A tree with a single node, a leaf containing an HPKE public key and credential for the creator

Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: 0 </del> <ins> Confirmed transcript hash: the zero-length octet string </ins> <del> Interim transcript hash: 0 </del> <ins> Interim transcript hash: the zero-length octet string </ins> Init secret: a fresh random value of size "KDF.Nh"
Change:
Immediately after I published draft-11, NAME noticed that I had failed to update the change log. This PR adds it to the editor's copy, so that it will be included in future versions.

Discussion:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-11 Include subtree keys in parent hash (*) Pin HPKE to draft-07 (*) Move joiner secret to the end of the first key schedule epoch (*) Add an AppAck proposal Make initializations of transcript hashes consistent </ins> draft-10 Allow new members to join via an external Commit (*)
Change:
(see issue for details).
Currently section "4. Protocol Overview" states: I think this is a legacy from before the propose/commit scheme and got carried over. New members no longer need the Commit. The subsequent diagram also needs to be adapted.

Discussion:
has received its Commit message back from the server does it update its state to reflect the new member's addition. <del> Upon receiving the Welcome message and the corresponding Commit, the new member will be able to read and send new messages to the group. Messages received before the client has joined the group are ignored. </del> <ins> Upon receiving the Welcome message, the new member will be able to read and send new messages to the group.  Messages received before the client has joined the group are ignored. </ins> Subsequent additions of group members proceed in the same way.  Any member of the group can download a KeyPackage for a new client and broadcast an Add message that the current group can use to update their state, and a Welcome message that the new client can use to <del> initialize its state. </del> <ins> initialize its state and join the group. </ins> To enforce the forward secrecy and post-compromise security of messages, each member periodically updates their leaf secret.  Any
Change:
It first reads as if MLS allows groups to communicate with each other, which I don't think is the intent.
Thanks Mark ;)

Discussion:
managed in GitHub, but any substantive change should be discussed on the MLS mailing list. <del> Groups of agents who want to send each other encrypted messages need a way to derive shared symmetric encryption keys.  For two parties, this problem has been studied thoroughly, with the Double Ratchet emerging as a common solution doubleratchet signal.  Channels </del> <ins> A group of agents 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 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. <del> For groups of size greater than two, a common strategy is to </del> <ins> For a group of size greater than two, a common strategy is to </ins> unilaterally broadcast symmetric "sender" keys over existing shared symmetric channels, and then for each agent to send messages to the group encrypted with their own sender key.  Unfortunately, while this
Change:
Add a missing word. Fail on blank leaf.
The is currently not very well described. Depending on the reading it might also be wrong. In particular, the condition , if implemented as described makes it so that valid parent hashes are rejected. Take for example a simple tree with two leafs where the right leaf (node 2) sends a commit. In this case the other leaf will reject the parent hash because it fails when going down to the right leaf. This might be a wrong interpretation of the described verification procedure but then the description needs updating. I suggest to add a more formal description of the parent hash generation and verification (e.g. pseudocode) to reduce ambiguity.
I think that condition should read "If R is a blank leaf node, the check fails".
Agree with NAME here; the matches this interpretation. So I think we just need to adjust that text.
I agree, this was fixed in

Discussion:
If R is blank, replace R with its left child until R is either non-blank or a leaf node <del> If R is a leaf node, the check fails </del> <ins> If R is a blank leaf node, the check fails </ins> If R.parent_hash is equal to the Parent Hash of P with Co-Path Child L, the check passes
Change:
This PR adds text to truncate the tree to perform garbage collection on removal. [ref: URL]
Over time we lost the rule that the ratchet tree should also be trimmed after members have been removed (where it really makes sense), not only when members are added.
NAME posted to address this issue
Fixed in - URL
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

Discussion:
Blank the intermediate nodes along the path from the removed leaf to the root <ins> Truncate the tree by reducing the size of tree until the rightmost non-blank leaf node </ins> 11.1.4. A PreSharedKey proposal can be used to request that a pre-shared key
Change:
202105 Interim: To be reviewed by editors.
Ready to merge modulo one nit.

Discussion:
a Commit message, who apply it to keep their local views of the tree in sync with the sender's.  More specifically, when a member commits a change to the tree (e.g., to add or remove a member), it transmits <del> an UpdatePath message containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf. The other members of the group use these values to update their view of the tree, aligning their copy of the tree to the sender's. </del> <ins> an UpdatePath containing a set of public keys and encrypted path secrets for intermediate nodes in the direct path of its leaf.  The other members of the group use these values to update their view of the tree, aligning their copy of the tree to the sender's. </ins> <del> To transmit this update, the sender broadcasts to the group the following information for each node in the direct path of the leaf, including the root: </del> <ins> An UpdatePath contains the following information for each node in the direct path of the sender's leaf, including the root: </ins> The public key for the node

The path secret value for a given node is encrypted for the subtree corresponding to the parent's non-updated child, that is, the child <del> on the copath of the leaf node.  There is one encrypted path secret for each public key in the resolution of the non-updated child. </del> <ins> on the copath of the sender's leaf node.  There is one encryption of the path secret to each public key in the resolution of the non- updated child. </ins> <del> The recipient of a path update processes it with the following steps: </del> <ins> The recipient of an UpdatePath processes it with the following steps: </ins> Compute the updated path secrets.
Change:
The spec doesn't say anything about the signature encoding yet. This PR adds a paragraph clarifying that signature encoding is done like in TLS.

Discussion:
the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. <ins> The signatures used throughout this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA signatures are defined as the concatenation of "r" and "s" as specified in RFC8032. </ins> Note that each new credential that has not already been validated by the application MUST be validated against the Authentication Service.
Change:
Most of these were stale; see comments for more specifics. I opened as a general issue arising from the final TODO.
Discussed at 20211004 interim, will merge after adding text in comment. NAME create new issue for multiple PSKs and PR for cascading HKDF.
The "Sequencing of State Changes" and "Application Messages" sections date to very early in the document's life, and probably need some updates to reflect current thinking.
Closing for now, might reopen based on WGLC review.

Discussion:
Note that, as a PSK may have a different lifetime than an update, it does not necessarily provide the same Forward Secrecy (FS) or Post- <del> Compromise Security (PCS) guarantees as a Commit message. </del> <ins> Compromise Security (PCS) guarantees as a Commit message.  Unlike the key pairs populated in the tree by an Update or Commit, which always freshly generated, PSKs may be pre-distributed and stored.  This creates the risk that a PSK may be compromised in the process of distribution and storage.  The security that the group gets from injecting a PSK thus depends on both the entropy of the PSK and the risk of compromise.  These factors are outside of the scope of this document, but should be considered by application designers relying on PSKs. </ins> Each PSK in MLS has a type that designates how it was provisioned. External PSKs are provided by the application, while recovery and re-
Change:
The math for left-balanced binary trees is very reliable once you have it right, but can be hard to get right from scratch. This PR provides an appendix that explains a theory and code for managing these trees.
I feel this is very useful to have in the draft for implementors. What should be the plan to merge it ? NAME
Thanks ! I expect that it's going to be very useful for implementers. I am trusting that it is correct Python syntax ;) Pointed out a potential typo in the comments.

Discussion:
in the Handshake Key Schedule to be ease chaining in case we switch design. (*) <ins> Added an appendix with example code for tree math </ins> draft-00 Initial adoption of draft-barnes-mls-protocol-01 as a WG item.
Change:
HPKE is in the RFC Editor queue, so there shouldn't be any further changes.
MLS draft-12 still references draft-08 of HPKE, which is now on draft-12. We should update to the final version of HPKE before finalizing MLS.

Discussion:
A signature algorithm <del> MLS uses draft-08 of HPKE I-D.irtf-cfrg-hpke for public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </del> <ins> MLS uses HPKE for public-key encryption I-D.irtf-cfrg-hpke.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol
Change:
I suggest that we consider including a ciphersuite that enables AES256 GCM with SHA384 and that for signatures ECDSA with P-384 (and SHA-384) is also permitted. The NSA restricts commercial applications to certain algorithms for applications that are used in or in coordination with the U.S. federal government and, from a general availability perspective, adding this could expand protocol use potential.
I presume you're thinking of here? I realize that the table specifies P-384 and SHA-384; is it your understanding that it forbids using bigger curves/hashes?
Both Suite B and alignment to the . The other options currently in the spec, size accounted for, do not align to requirements.
You didn't answer my question about forbidding the use of bigger curves/hashes. Would the cases you're interested in be covered by the AES-256 / SHA-512 / P-521 suite?
If this is needed for the reasons mentioned in the issue, I have no objections.

Discussion:
as follows I-D.irtf-cfrg-hpke RFC8446: The hash used for the MLS transcript hash is the one referenced in <del> the ciphersuite name.  In the ciphersuites defined above, "SHA256" and "SHA512" refer to the SHA-256 and SHA-512 functions defined in SHS. </del> <ins> the ciphersuite name.  In the ciphersuites defined above, "SHA256", "SHA384", and "SHA512" refer to the SHA-256, SHA-384, and SHA-512 functions defined in SHS. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, <del> therefore the ciphersuites only inlcude modern, yet well-established </del> <ins> therefore the ciphersuites only include modern, yet well-established </ins> algorithms.  Depending on their requirements, clients can choose between two security levels (roughly 128-bit and 256-bit).  Within the security levels clients can choose between faster X25519/X448
Change:
A GroupInfo (or a PublicGroupState) should only ever contain one RatchetTreeExtension. Either that or it should be specified what happens if there is more than one.
Seems like we should be able to make a general proclamation that extension IDs MUST be unique in a given vector of extensions, whether that's GroupContext, KeyPackage, GroupInfo, GroupContextExtensions, etc.
Sounds good to me. I'll draft a PR.
SGTM, one minor rephrasing for more clarity.

Discussion:
those in the GroupInfo object, according to the definitions of those extensions. <ins> Any field containing a list of extensions MUST NOT have more than one extension of any given type. </ins> Note that the latter two requirements mean that all MLS extensions are mandatory, in the sense that an extension in use by the group MUST be supported by all members of the group.
Change:
The padding section was out of date based on prior changes.
In section 14.1 Message Encryption and Decryption there is a paragraph describing the reasons why you would want to use padding, and part of that mentions the following As the padding mechanism is used to improve protection against traffic analysis, removal of the padding SHOULD be implemented in a "constant-time" manner at the MLS layer and above layers to prevent timing side-channels that would provide attackers with information on the size of the plaintext. The padding length lengthofpadding can be chosen at the time of the message encryption by the sender. This seems out of date given that padding is a separate field that doesn't need to be explicitly stripped off at decrypt time and there is no other mention of in the document.
That seems right. We used to have a more clever, more economical padding scheme mirroring what TLS does. But that got rationalized a while ago. These are probably dangling references. Want to send a PR?
Sounds good, pushed PR URL

Discussion:
find out the plaintext by correlation between the question and the length. <del> Similarly to TLS 1.3, if padding is used, the MLS messages MUST be padded with zero-valued bytes before AEAD encryption.  Upon AEAD decryption, the length field of the plaintext is used to compute the number of bytes to be removed from the plaintext to get the correct data.  As the padding mechanism is used to improve protection against traffic analysis, removal of the padding SHOULD be implemented in a "constant-time" manner at the MLS layer and above layers to prevent timing side-channels that would provide attackers with information on the size of the plaintext.  The padding length length_of_padding can be chosen at the time of the message encryption by the sender. Recipients can calculate the padding size from knowing the total size of the ApplicationPlaintext and the length of the content. </del> <ins> The content and length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  It is recommended that padding data is comprised of zero-valued bytes and follows an established deterministic padding scheme. </ins> 14.2.
Change:
Note: If you have an existing clone, you will need to delete at the root level of the clone in order for to work. ( will still work fine)

Discussion:
The Messaging Layer Security (MLS) Protocol <del> draft-barnes-mls-protocol-latest </del> <ins> draft-ietf-mls-protocol-latest </ins> Abstract

RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this draft is maintained in GitHub.  Suggested changes should be submitted <del> as pull requests at https://github.com/ekr/mls-protocol. </del> <ins> as pull requests at https://github.com/mlswg/mls-protocol. </ins> Instructions are on that page as well.  Editorial changes can be managed in GitHub, but any substantive change should be discussed on the MLS mailing list.
Change:
Adjust ASCII art to fit within 72 character limit. Did not fix tables or code in appendices.

Discussion:
"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 <del> invocations, as follows: </del> <ins> invocations (labelled "Extract" for brevity in the diagram), as follows: </ins> In particular, if there are no PreSharedKey proposals in a given Commit, then the resulting "psk_secret" is "psk_secret_[0]", the all-
Change:
The definition of an MLS group in the 2nd paragraph of the Protocol Overview is really good. Let's use it as the definition in the Terminology section as well.

Discussion:
state with other clients.  A client is defined by the cryptographic keys it holds. <del> A linear sequence of epochs in which each epoch depends on its </del> <ins> A group represents a logical collection of clents that share a common secret value at any given time.  Its state is represented as a linear sequence of epochs in which each epoch depends on its </ins> predecessor. A state of a group in which a specific set of authenticated
Change:
In the most basic case, the resolution of a node is the node, so let's say that.
Fwiw this is stated immediately below your note:
Bren2010 said: >Fwiw this is stated immediately below your note: Yes. And it took me three readings to understand that the most complicated scenario was being described first and the most basic scenario is not explicitly stated. Most readers will not understand in what cases there will be unmerged leaves by this point.
Looks good with one minor edit.

Discussion:
A node in the tree may also be _blank_, indicating that no value is present at that node.  The _resolution_ of a node is an ordered list of non-blank nodes that collectively cover all non-blank descendants <del> of the node.  The resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </del> <ins> of the node.  The resolution of a non-blank node with no unmerged leaves is just the node itself.  More generally, the resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </ins> The resolution of a non-blank node comprises the node itself, followed by its list of unmerged leaves, if any
Change:
In the Protocol Overview, Figure 1 shows a ratchet tree, commitsecret, epochsecret, encryptionsecret, and a secret tree, while the text discusses the epochsecret and encryption_secret. Then the next section, Cryptographic State and Evolution states that "There are two types of cryptographic state at the core of MLS:" a key schedule, and a ratchet tree. The Secret Tree isn't mentioned there. Then we have a Key Schedule section which then includes a Secret Tree sub-section. Readers are left wondering what the relationship is between the the Key Schedule and Secret Tree.

Discussion:
efficiently encrypt messages to subsets of the group.  Each epoch has a distinct ratchet tree. <del> Each member of the group maintains a view of these two facets of the </del> <ins> A _secret tree_ derived from the key schedule that represents shared secrets used by the members of the group to provide confidentiality and forward secrecy for MLS messages.  Each epoch has a distinct secret tree. Each member of the group maintains a view of these facets of the </ins> group's state.  MLS messages are used to initialize these views and keep them in sync as the group transitions between epochs.

key schedule also defines a collection of secrets that are derived from the epoch secret.  For example: <del> An _encryption secret_ that is used to initialize a _secret tree_, which provides keys for encrypting handshake and application messages and providing forward secrecy for these messages within an epoch. </del> <ins> An _encryption secret_ that is used to initialize the secret tree for the epoch. </ins> A _confirmation key_ that is used to confirm that all members agree on the shared state of the group.
Change:
Note that is currently under , so that should probably move or the top level section should be renamed. I ran out of imagination for today.

Discussion:
4.1. <del> There are two types of cryptographic state at the core of MLS: A _key schedule_ that represents the shared secret state of the group and its evolution from one epoch to the next. </del> <ins> The cryptographic state at the core of MLS is divided into three areas of responsibility: </ins> A _ratchet tree_ that represents the membership of the group, providing group members a way to authenticate each other and efficiently encrypt messages to subsets of the group.  Each epoch <del> has a distinct ratchet tree. </del> <ins> has a distinct ratchet tree.  It seeds the _key schedule_. A _key schedule_ that describes the chain of key derivations used to progress from epoch to epoch (mainly using the _init_secret_ and _epoch_secret_); and to derive a variety of other secrets (see epoch-derived-secrets) used during the current epoch.  One of these (the _encryption_secret_) is the root of _secret_tree_. </ins> A _secret tree_ derived from the key schedule that represents shared secrets used by the members of the group to provide