jiebi/TextFlow huggingface dataset:
Original text:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages, <del> such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </del>  The attacker can read, write, and delete arbitrary messages inside the secure transport channel.

Reviewer comments:
I'll add references for QUIC, TLS, IPsec, WireGuard, and TOR. Update: Created
Comment by NAME It is a bit odd to mention a non-IETF VPN protool, but not the IETF VPN protocol. Especially since IPsec also has constant byte stream support via IPTFS that WireGuard does not have :P
This is just a list of examples, it doesn't need to cover everything in the universe. And IETF docs are allowed to mention non-IETF things.

Revised text:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages,  <ins> such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.
Original text:
However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The <del> protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del>  Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply

Reviewer comments:
Comment by NAME It scares me a bit that this could possibly not be detected at all? What is the scenario where it cannot be detected?
It's actually non-trivial to guarantee detection. Consider a scenario like the following: A, B, C, D are in a group The DS decides to partition the group into (AB) (CD) The DS forwards commits and messages within a partition, but not across partitions. As a result, the two subgroups work fine, but they diverge from each other This will be immediately obvious if two participants in opposite partitions ever try to compare state across the partition boundary, say by checking whether a message arrived or even by comparing the value. But it will be invisible if nobody does -- it just looks like the other partition is offline at the moment. And note that comparing across the partition boundary has to be done out of band, because the DS is blocking in-band comms across the boundary. To prevent this with any reliability, you would need a consensus protocol by which a quorum of members verify that they've received a Commit. And even then, the members outside any particular quorum could be partitioned. In any case, designing a consensus protocol is clearly outside the MLS WG charter. The silver lining here, as the document notes, is that the protocol fails closed. If two members have different views of the group, then they cannot communicate.
This is only true wrt to handshake messages. The DS can still reorder and provide an inconsistent view of application messages. We intentionally punted this to an extension (which I realize now we never specified in the extensions doc) to give applications leeway in the ordering/delivery guarantees provided to application messages. Handshake messages require reliable and in-order but application messages may or may not.

Revised text:
However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The  <ins> "generation" counter in MLS messages provides per-sender loss detection and ordering that cannot be manipulated by the DS.  A mechanism for more robust protections is discussed in I-D.ietf-mls- extensions.  A DS can cause a partition in the group by partitioning key exchange messages; this can be detected only by out of band comparison (e.g., confirming that all clients have the same "epoch_authenticator" value`). </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply
Original text:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure <del> channel can be used as a transport layer to protect MLS messages, such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </del>  The attacker can read, write, and delete arbitrary messages inside the secure transport channel.

Reviewer comments:
There have been a lot of comments about the inclusion of WireGuard and Tor as potential secure transports, but I actually think it's confusing to cite IPsec as well for layering issues. We don't have a real praxis for using things that aren't application-layer style protocols for protecting this kind of traffic, so I don't think we should encourage these. I've trimmed it to just QUIC and TLS.

Revised text:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure  <ins> channel, such as QUIC RFC9000, TLS RFC8446, can be used to transport MLS messages.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.
Original text:
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>  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

Reviewer comments:
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 !

Revised text:
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  <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
Original text:
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>  authenticated using the Client's identity key.  Thus, the Client stores:

Reviewer comments:
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.

Revised text:
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  <ins> of the shared group key.  This initial keying material is </ins> authenticated using the Client's identity key.  Thus, the Client stores:
Original text:
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>  3.2.

Reviewer comments:
In the section 3.1.7. Compatibility with future versions of MLS, the word "messages" is duplicated.
Thanks

Revised text:
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  <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.
Original text:
3.1.3. <del> It is typically expected for users within Group to own different </del>  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>  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>  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

Reviewer comments:
There were some odd formulations in section 3.1.3. I hope I addressed those issues without changing the intended meaning.

Revised text:
3.1.3.  <ins> It is typically expected for users within a Group to own different </ins> devices.  <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  <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
Original text:
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>  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>  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>  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>  (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

Reviewer comments:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thanks NAME !

Revised text:
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  <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.  <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  <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  <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
Original text:
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>  2.2.

Reviewer comments:
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!

Revised text:
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.  <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.
Original text:
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>  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

Reviewer comments:
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.

Revised text:
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  <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
Original text:
message per epoch. Much like the Authentication Service, the Delivery Service can be <del> split between server and client components.  Acheiving required </del>  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:

Reviewer comments:
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!

Revised text:
message per epoch. Much like the Authentication Service, the Delivery Service can be  <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:
Original text:
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.  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>  It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this

Reviewer comments:
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

Revised text:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions.  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.  <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
Original text:
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.

Reviewer comments:
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

Revised text:
The delivery service will return one or more client init key bundles, one for each member.  6. 6.1.