jiebi/CodeConvo huggingface dataset:
Change:
Change reference to XMPP to the current RFC. Change heading of "Deniability" section, which also discusses non-repudiation, to "Non-Repudiation and Deniability". I wondered if that latter section should note that a third-party (ie, non-Member) cannot identify a sender from a given encrypted message, but then I wondered if that was the case or not.
Thanks NAME !

Discussion:
document) and an abstract protocol MLSPROTO for providing end-to-end security in this setting.  MLS is not intended as a full instant messaging protocol but rather is intended to be embedded in a <del> concrete protocol such as XMPP RFC3920.  In addition, it does not </del> <ins> concrete protocol such as XMPP RFC6120.  In addition, it does not </ins> specify a complete wire encoding, but rather a set of abstract data structures which can then be mapped onto a variety of concrete encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON
Change:
Removing 2119 "MUST" as agreed in Paris. Note that this is the minimal change and in another PR I will suggest removing as many lower case instances of must, should, etc. as possible.

Discussion:
Upon joining the system, each Client stores its initial cryptographic key material with the DS.  This key material represents the initial contribution from each member that will be used in the establishment <del> of the shared group key.  This initial keying material MUST be </del> <ins> of the shared group key.  This initial keying material is </ins> authenticated using the Client's identity key.  Thus, the Client stores:
Change:
The current naming is confusing: MS stands for "Message Switch" and "Messaging Server" but not for "Messaging Service" AS stands for "Authentication Server" and "Authentication Service". The proposed change gives: MS as "Messaging Service" (AS* + DS) AS as "Authentication Service" DS as "Delivery Service" the "Server"s being the endpoints and not the functionality

Discussion:
A model system is shown in [TODO: Figure]. <del> The messaging service presents as two abstract services: </del> <ins> The Messaging Service (MS) presents as two abstract services: </ins> <del> An Authentication Server (AS) which is responsible for maintaining user identities, issuing credentials which allow them to authenticate to each other, and potentially distributing user </del> <ins> An Authentication Service (AS) which is responsible for maintaining user identities, issuing credentials which allow them to authenticate to each other, and potentially distributing user </ins> keying material. <del> A Message Switch (MS) which is responsible for delivering messages between users.  In the case of group messaging, the message switch may also be responsible for acting as an "exploder" where the sender sends a single message to a group and the switch then forwards it to each recipient. </del> <ins> A Delivery Service (DS) which is responsible for delivering messages between users.  In the case of group messaging, the delivery service may also be responsible for acting as an "exploder" where the sender sends a single message to a group and the switch then forwards it to each recipient. </ins> <del> In many systems, the AS and the MS are actually operated by the same </del> <ins> In many systems, the AS and the DS are actually operated by the same </ins> entity and may even be the same server.  However, they are logically distinct and, in other systems, may be operated by different entities so we show them as separate here.  Other partitions are also

Alice, Bob, and Charlie create accounts with the messaging service and obtain credentials from the AS. <del> Alice, Bob, and Charlie authenticate to the MS and store some </del> <ins> Alice, Bob, and Charlie authenticate to the DS and store some </ins> keying material which can be used to encrypt to them for the first time. When Alice wants to send a message to Bob and Charlie, she <del> contacts the MS and looks up their keying material.  She uses </del> <ins> contacts the DS and looks up their keying material.  She uses </ins> those keys to establish a set of keys which she can use to send to Bob and Charlie.  She then sends the encrypted message(s) to the <del> MS, which forwards them to the ultimate recipients. </del> <ins> DS, which forwards them to the ultimate recipients. </ins> Bob and/or Charlie respond to Alice's message.  Their messages might include new keys which allow the joint keys to be updated,
Change:
Remove "join an existing group" from architecture doc, based on UserAdd having been removed from the protocol doc. Remove statement that message delivery cannot be correlated between AS identities and DS delivery channels. This seems generally very difficult to achieve. It may be possible at times, but does not seem to be grounded in discussions that we have had at the working group meetings. Note that federation requires compatible wire encodings. Note that communication with the AS requires TLS or alternative authentication. Note that out-of-band channels may facilitate detection of misbehaviour. Some grammar fixes.

Discussion:
The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can <del> interoperate and to form federated systems. </del> <ins> interoperate and to form federated systems if they use compatible wire encodings. </ins> 3.1.7.

We assume that all transport connections are secured via some transport layer security mechanism such as TLS I-D.ietf-tls-tls13. However, as noted above, the security of MLS will generally survive <del> compromise of the transport layer. </del> <ins> compromise of the transport layer, so long as identities provided by the AS are authenticated at a minimum. </ins> 3.2.2.

A corollary to this statement is that the AS and the DS cannot read the content of messages sent between Members as they are not Members <del> of the Group.  MLS optionally provide additional protections </del> <ins> of the Group.  MLS optionally provides additional protections </ins> regarding traffic analysis so as to reduce the ability of adversaries, or a compromised member of the messaging system, to deduce the content of the messages depending on (for example) their

In general we do not consider Denial of Service (DoS) resistance to be the responsibility of the protocol.  However, it should not be <del> possible for anyone to perform a trivial DoS attack from which it is hard to recover. </del> <ins> possible for anyone aside from the DS to perform a trivial DoS attack from which it is hard to recover. </ins> 3.2.2.5.

including total DoS attacks (where it simply refuses to forward any messages) and partial DoS attacks (where it refuses to forward messages to and from specific Clients).  As noted in delivery- <del> guarantees, these attacks are only partially detectable by clients. Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology. </del> <ins> guarantees, these attacks are only partially detectable by clients without an out-of-band channel.  Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology. </ins> Because the DS is responsible for providing the initial keying material to Clients, it can provide stale keys.  This does not
Change:
In the section 3.1.7. Compatibility with future versions of MLS, the word "messages" is duplicated.
Thanks

Discussion:
It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this mechanism prevents version downgrade attacks where an attacker would <del> actively rewrite messages messages with a lower protocol version than the ones originally offered by the endpoints.  When multiple versions of MLS are available, the negotiation protocol guarantees that the version agreed upon will be the highest version supported in common by the group. </del> <ins> actively rewrite messages with a lower protocol version than the ones originally offered by the endpoints.  When multiple versions of MLS are available, the negotiation protocol guarantees that the version agreed upon will be the highest version supported in common by the group. </ins> 3.2.
Change:
There were some odd formulations in section 3.1.3. I hope I addressed those issues without changing the intended meaning.

Discussion:
3.1.3. <del> It is typically expected for users within Group to own different </del> <ins> It is typically expected for users within a Group to own different </ins> devices. <del> A new device can be added to a group by sharing of an existing client secrets or be considered as a new client by the protocol.  This client will not gain access to the history even if it is owned by someone who owns another member of the Group.  Restoring history is typically not allowed at the protocol level but applications can </del> <ins> A new device can either be added to a group by sharing secrets of an existing client or be considered as a new client by the protocol. This client will not gain access to the history even if it is owned by someone who owns another member of the Group.  Restoring history is typically not allowed at the protocol level but applications can </ins> elect to provide such a mechanism outside of MLS. 3.1.4.

MLS adopts the Internet threat model RFC3552 and therefore assumes that the attacker has complete control of the network.  It is <del> intended to provide the security services described in in the face of </del> <ins> intended to provide the security services described in the face of </ins> such attackers.  In addition, these guarantees are intended to degrade gracefully in the presence of compromise of the transport security links as well as of both clients and elements of the
Change:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thanks NAME !

Discussion:
This document describes the reference architecture, functional and security requirements for the Messaging Layer Security (MLS) protocol.  MLS provides a security layer for group messaging <del> applications with from two to a large number of clients.  It is meant to protect against eavesdropping, tampering, and message forgery. </del> <ins> applications, where the number of clients ranges from two to many. It is meant to protect against eavesdropping, tampering, and message forgery. </ins> 1.

services at their disposal to establish the necessary values and credentials required for encryption and authentication. <del> The Messaging Service (MS) presents as two abstract services that allow clients to prepare for sending and receiving messages securely: </del> <ins> The Messaging Service (MS) presents two abstract services that allow clients to prepare for sending and receiving messages securely: </ins> An Authentication Service (AS) which is responsible for maintaining user long term identities, issuing credentials which allow them to authenticate each other, and potentially allowing <del> users to discover each others long-term identity keys. </del> <ins> users to discover each other's long-term identity keys. </ins> A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members.  In the case of

The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the <del> delivery of messages and avoid Personally Identifiable Information </del> <ins> delivery of messages and avoids Personally Identifiable Information </ins> (PII) or other sensitive metadata wherever possible.  A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with
Change:
Minor corrections throughout from joint edits by NAME NAME and NAME Some description text added.
In the section "Groups, Members, and Clients", the definition of a group in MLS is the set of clients that have knowledge of the shared group key, which is established in the group key exchange. The spec then goes on to say that "Until a Member has contributed to the group secret, other members cannot assume she is a member of the group." This phrasing of what constitutes a group member is quite weak and does not actually reflect the security properties of the underlying group key exchange. If a member has not contributed to the shared group secret, she cannot be considered a member of the group, as 1) she should not be able to learn the group key (without acting adversarially outside of the protocol), and 2) other members cannot verify her membership Instead, I would rephrase this description of a member/non-member to say something stronger, like "Until a Member has been added to the group by another member---thereby requiring that she contributes to the group secret in this process in such a way that is verifiable to other group members--she will not be able to participate as a member of the group."
Good idea. An edit on this has been added to PR .
I might be missing something here: Can't a party be added to a group (thus learning the group secret) and from that point never contribute to the shared group secret? That party would still be able to encrypt and decrypt application messages.
Hi NAME could you please check the current document and propose a new phrasing if needed? Thanks : )
NAME confirmed to me offline that this issue was addressed in
Modulo a few nits that can be fixed post-merge, this looks quite good Thanks to you three for the PR!

Discussion:
The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it. <del> Until a Member has contributed to the group secret, other members cannot assume they are a member of the group. </del> <ins> Until a Member has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the Member is a member of the group. </ins> 2.2.
Change:
Mainly focused on cleaning up grammar, but also fixing some things that have gone stale, like the idea that the MLS protocol is "abstract".
This looks good ! Thank you !
Looks good! Just two comments on client identity.

Discussion:
and a public signature key.  Ownership of a client by a user is determined by the fact that the user has knowledge of the associated secret values.  When a client is part of a Group, it is called a <del> Member and its signature key pair uniquely identifies it to other clients or members in the Group.  In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this. Users will often use multiple clients, potentially one or more per device (phones, web clients or other devices...), and may choose to authenticate using the same signature key across devices, using one signature key per device or even one signature key per group. </del> <ins> Member.  In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this. Users will often use multiple devices, e.g., a phone as well as a laptop.  Different devices may be represented as different clients, with independent cryptographic state, or they may share cryptographic state, relying on some application-provided mechanism to sync across devices. </ins> The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group
Change:
This edit got a little invasive, largely around the "ordering" requirements. As was already pointed out the epoch numbering provides ordering to first order. What is really needed is for the DS to select a single Commit per epoch.
Thanks for the PR! Left a few comments, but otherwise looks good!

Discussion:
message per epoch. Much like the Authentication Service, the Delivery Service can be <del> split between server and client components.  Acheiving required </del> <ins> split between server and client components.  Achieving the required </ins> uniqueness property will typically require a combination of client and server behaviors.  For example, all of the following examples provide a unique Commit per epoch:
Change:
I added a short section after discussing architectural issues for content framing and negotiation. It suggests [1] if the application doesn't have a more specific proposal. [1] URL
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in

Discussion:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del> 5.8. <ins> Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. 5.9. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can

authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.9. </del> <ins> 5.10. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this
Change:
This should give you the same GitHub pages website as mls-protocol. One this is merged, someone with push access to the repo will need to run: It doesn't look like Pages it on. You can try turning it off and back on in the Settings tab and that will trigger a new deploy. Leave the domain for Pages as the default, not "URL" or something similar
NAME Do you mind reviewing?
NAME Can you follow the instructions in the PR description please

Discussion:
The delivery service will return one or more client init key bundles, one for each member. <del> OPEN QUESTION: What if different clients have different cipher suites? </del> 6. 6.1.
Change:
For now, I've only touched the sections until the "Cryptographic Objects" section, which seems to be outdated anyway. Once those are updated at some point, I'm happy to help moving from hashing to KDF-derivation there as well.
Thanks Konrad ! : )

Discussion:
A Diffie-Hellman finite-field group or elliptic curve <del> A Derive-Key-Pair function that produces a key pair from an octet string </del> <ins> A Key Derivation Function (KDF) </ins> <del> A hash function </del> <ins> A Derive-Public-Key function that produces a public key from a private key </ins> A ratchet tree is a left-balanced binary tree, in which each node contains up to three values:

An asymmetric public key <del> The private key and public key for a node are derived from its secret value using the Derive-Key-Pair operation. </del> <ins> The private key for a node is derived from its secret value using the KDF.  The public key is then derived from the private key using the Derive-Public-Key function. </ins> The contents of a parent node are computed from one of its children as follows:

updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from <del> the resolution node * Compute secret values for ancestors of that node by hashing the decrypted secret </del> <ins> the resolution node * Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For
Change:
There is no "leaf_secret" field in GroupState. While there might be one in the group state struct that the implementation maintains locally, I think it's safe to recommend copying everything from the GroupState object as it's defined earlier in the document.

Discussion:
Since the new member is expected to process the Add message for itself, the Welcome message should reflect the state of the group before the new user is added.  The sender of the Welcome message can <del> simply copy all fields except the "leaf_secret" from its GroupState object. </del> <ins> simply copy all fields from their GroupState object. </ins> [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the