Change:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.

Discussion:
This document specifies version 1.0 of the Messaging Layer Security (MLS) protocol.  MLS allows group messaging for a large number of <del> clients over a network with the help of a delivery service for messages, and potentially an authentication service to provide long term identity keys, in a way that is designed to prevent eavesdropping, tampering, and message forgery. </del> <ins> networked clients by providing a delivery service for messages, and potentially an authentication service, in a way that is designed to prevent eavesdropping, tampering, and message forgery. </ins> 1. End-to-end security is a requirement for instant messaging systems <del> and is commonly deployed in many such systems designed over the past few years.  In this context, what end-to-end means is that the users of the system enjoy some level of security - with the precise level depending on the system design - even when the messaging service they are using misbehaves. </del> <ins> and is commonly deployed in many such systems.  In this context, "end-to-end" captures the notion that users of the system enjoy some level of security - with the precise level depending on the system design - even when the messaging service they are using performs unsatisfactorily. </ins> Messaging Layer Security (MLS) specifies an architecture (this document) and an abstract protocol [TODO:XREF] for providing end-to-

encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON RFC7159.  Implementations which adopt compatible encodings should be able to have some degree of interoperability at the message level <del> (though perhaps not at the authentication level). </del> <ins> (though perhaps not at the authentication level).  [[TvdM: What precisely do we mean by authentication level here?  Also, it's not clear, upon initial reading of this section, what the purpose of this document is.  Perhaps we should be more explicit in explain why it's necessary?]] </ins> 2. <del> A Group using a Messaging Service (MS) is a set of participants called Members where each Member is typically expected to own multiple devices called Clients.  In order to communicate securely, Group Members first use services at their disposal to obtain necessary secrets and credentials required for security. </del> <ins> A Group using a Messaging Service (MS) comprises a set of participants called Members where each Member is typically expected to own multiple devices, called Clients.  In order to communicate securely, Group Members initially use services at their disposal to obtain the necessary secrets and credentials required for security. </ins> The Messaging Service (MS) presents as two abstract services that <del> allow Members to prepare before sending and receiving messages securely : </del> <ins> allow Members 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 to each other, and potentially <del> distributing user signing keying material. </del> <ins> distributing user signing keys. </ins> A Delivery Service (DS) which is responsible for receiving and redistributing messages between group members.  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 which is then forwarded to each recipient in the group. <del> The DS is also responsible to store and deliver initial public keying material required to proceed with the group secret key establishment process. </del> <ins> The DS is also responsible for storing and delivering initial public key material required in order to proceed with the group secret key establishment process. [[ TvdM: "exploder" may be strange term to use here, "message amplifier" maybe?]] </ins> In many systems, the AS and the DS are actually operated by the same entity and may even be the same server.  However, they are logically <del> distinct and, in other systems, may be operated by different entities so we show them as separate here.  Other partitions are also possible, such as having a separate directory server. </del> <ins> distinct and, in other systems, may be operated by different entities, hence we show them as being separate here.  Other partitions are also possible, such as having a separate directory server. </ins> <del> A typical scenario might look something like this: </del> <ins> A typical scenario might look like this: </ins> <del> Alice, Bob, and Charlie create accounts with a messaging service </del> <ins> Alice, Bob and Charlie create accounts with a messaging service </ins> and obtain credentials from the AS. <del> Alice, Bob, and Charlie authenticate to the DS and store some initial keying material which can be used to encrypt to them for the first time. </del> <ins> Alice, Bob and Charlie authenticate to the DS and store some initial keying material which can be used to send encrypted messages to them for the first time. </ins> When Alice wants to send a message to Bob and Charlie, she contacts the DS and looks up their initial keying material.  She <del> uses those keys to establish a new set of keys which she can use to send to Bob and Charlie.  She then sends the encrypted message(s) to the DS, which forwards them to the ultimate </del> <ins> uses these keys to establish a new set of keys which she can use to send encrypted messages to Bob and Charlie.  She then sends the encrypted message(s) to the DS, which forwards them to the </ins> recipients. Bob and/or Charlie respond to Alice's message.  Their messages might trigger a new key derivation step which allows the shared group key to be updated, thus providing post-compromise security. <del> 2.1. Roles: Clients in groups (and by extension Members) have equal rights for managing groups and sending messages, unless specified otherwise outside the protocol, typically at the application layer. </del> <ins> Clients in groups (and by extension Members) have equal rights for managing groups and sending messages, unless specified otherwise outside of the messaging protocol, typically at the application layer.  Clients may wish to do the following: </ins> <del> I want to create a group by inviting other members </del> <ins> create a group by inviting other members </ins> <del> I want to add one or more members to an existing group </del> <ins> add one or more members to an existing group </ins> <del> I want to remove one or more members from an existing group </del> <ins> remove one or more members from an existing group </ins> <del> I want to join an existing group </del> <ins> join an existing group </ins> <del> I want to leave a group </del> <ins> leave a group </ins> <del> I want to send a message to everyone in the group </del> <ins> send a message to everyone in the group </ins> <del> I want to receive a message from someone in the group </del> <ins> receive a message from someone in the group </ins> <del> 2.2. </del> <ins> 2.1. </ins> In MLS a Group is defined as a set of Members who possibly use multiple endpoint devices to interact with the Messaging Service. <del> Only endpoints that are not an AS nor a DS are called Clients.  These </del> <ins> Only endpoints that are not an AS or a DS are called Clients.  These </ins> clients will typically correspond to end-user devices such as phones, web clients or other devices running MLS.

a phone) or sequentially (e.g., replacing one phone with another), hence the formal definition of a Group in MLS is the set of Clients that has legitimate knowledge of the shared (Encryption) Group Key <del> established throughout the group key establishment phase of the protocol. </del> <ins> established in the group key establishment phase of the protocol. </ins> MLS has been designed to provide similar security guarantees to all Clients, for all group sizes, even when it reduces to only two Clients. <del> 2.3. </del> <ins> 2.2. </ins> The Delivery Service (DS) is expected to play multiple roles in the Messaging Service architecture.

Delivery Service, the functionnal and security guarantees provided by MLS may differ. <del> 2.3.1. </del> <ins> 2.2.1. </ins> In the MLS group communication establishment process, the first step exercised by the DS is to store the initial cryptographic key

examine the KT log, if available, to make sure the keys they will be using are correct. <del> 2.3.2. </del> <ins> 2.2.2. </ins> Delivery in order and resilience against intermittent message loss are the two main properties expected by MLS from the DS.  Another

correct delivery will not be trusted regarding the group membership information either. <del> 2.3.3. </del> <ins> 2.2.3. </ins> A particularly important security constraint in that an adversary must not be able to gain access to information about the identity of

counter measures against potential traffic analysis that could be done at the DS level. <del> 2.3.4. </del> <ins> 2.2.4. </ins> Clients that have been offline for a long time or not performing mandatory security operations will affect the security of the group

to preserve security properties such as forward secrecy of messages or post-compromise security. <del> 2.4. </del> <ins> 2.3. </ins> New Members to the Messaging Service will always need to provide some initial keying material for other users to potentially use when