Draft: draft-ietf-mls-protocol

Commentary: Aligning the terminology across the two documents after discussion . 
 Ok , I think this is ready , please have a look .. I believe the changes are reasonably concise , the use of client seems better in some places than participant was and does n't feel odd to me . 
 LGTM
Paragraph (version A):
Messaging applications are increasingly making use of end-to-end
security mechanisms to ensure that messages are only accessible to
the communicating endpoints, and not to any servers involved in
delivering messages.  Establishing keys to provide such protections
is challenging for group chat settings, in which more than two
participants need to agree on a key but may not be online at the same
time.  In this document, we specify a key establishment protocol that
provides efficient asynchronous group key establishment with forward
secrecy and post-compromise security for groups in size ranging from
two to thousands.
Paragraph (version B):
Messaging applications are increasingly making use of end-to-end
security mechanisms to ensure that messages are only accessible to
the communicating endpoints, and not to any servers involved in
delivering messages.  Establishing keys to provide such protections
is challenging for group chat settings, in which more than two
clients need to agree on a key but may not be online at the same
time.  In this document, we specify a key establishment protocol that
provides efficient asynchronous group key establishment with forward
secrecy and post-compromise security for groups in size ranging from
two to thousands.
Paragraph (version A):
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
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.
Paragraph (version A):
For a group of size greater than two, a common strategy is to
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
improves efficiency over pairwise broadcast of individual messages
and (with the addition of a hash ratchet) provides forward secrecy,
it is difficult to achieve post-compromise security with sender keys.
An adversary who learns a sender key can often indefinitely and
passively eavesdrop on that sender's messages.  Generating and
distributing a new sender key provides a form of post-compromise
security with regard to that sender.  However, it requires
computation and communications resources that scale linearly as the
size of the group.
Paragraph (version B):
A group of users 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
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.
Paragraph (version B):
For a group of size greater than two, a common strategy is to
unilaterally broadcast symmetric "sender" keys over existing shared
symmetric channels, and then for each member to send messages to the
group encrypted with their own sender key.  Unfortunately, while this
improves efficiency over pairwise broadcast of individual messages
and provides forward secrecy (with the addition of a hash ratchet),
it is difficult to achieve post-compromise security with sender keys.
An adversary who learns a sender key can often indefinitely and
passively eavesdrop on that member's messages.  Generating and
distributing a new sender key provides a form of post-compromise
security with regard to that sender.  However, it requires
computation and communications resources that scale linearly with the
size of the group.
Paragraph (version A):
An agent that uses this protocol to establish shared cryptographic
state with other participants.  A participant is defined by the
cryptographic keys it holds.  An application may use one
participant per device (keeping keys local to each device) or sync
keys among a user's devices so that each user appears as a single
participant.
Paragraph (version A):
A collection of participants with shared cryptographic state.
Paragraph (version A):
A participant that is included in the shared state of a group, and
has access to the group's secrets.
Paragraph (version A):
A short-lived HPKE key pair used to introduce a new member to a
group.  Initialization keys are published for individual
participants (UserInitKey).
Paragraph (version A):
A short-lived HPKE key pair that represents a group member's
contribution to the group secret, so called because the
participants leaf keys are the leaves in the group's ratchet tree.
Paragraph (version B):
An agent that uses this protocol to establish shared cryptographic
state with other clients.  A client is defined by the
cryptographic keys it holds.  An application or user may use one
client per device (keeping keys local to each device) or sync keys
among a user's devices so that each user appears as a single
client.
Paragraph (version B):
A collection of clients with shared cryptographic state.
Paragraph (version B):
A client that is included in the shared state of a group, hence
has access to the group's secrets.
Paragraph (version B):
A short-lived HPKE key pair used to introduce a new client to a
group.  Initialization keys are published for each client
(UserInitKey).
Paragraph (version B):
A secret that represent a member's contribution to the group
secret (so called because the members' leaf keys are the leaves in
the group's ratchet tree).
Paragraph (version A):
A long-term identity key provider which allows participants to
authenticate protocol messages in a group.  These keys MUST be
kept for the lifetime of the group as there is no mechanism in the
protocol for changing a participant's identity key.
Paragraph (version A):
A directory to which participants can publish initialization keys,
and from which participant can download initialization keys for
other participants.
Paragraph (version A):
The goal of this protocol is to allow a group of participants to
exchange confidential and authenticated messages.  It does so by
deriving a sequence of secrets and keys known only to group members.
Those should be secret against an active network adversary and should
have both forward and post-compromise secrecy with respect to
compromise of a participant.
Paragraph (version A):
We describe the information stored by each participant as a _state_,
which includes both public and private data.  An initial state,
including an initial set of participants, is set up by a group
creator using the _Init_ algorithm and based on information pre-
published by the initial members.  The creator sends the _Init_
message to the participants, who can then set up their own group
state and derive the same shared secret.  Participants then exchange
messages to produce new shared states which are causally linked to
their predecessors, forming a logical Directed Acyclic Graph (DAG) of
states.  Participants can send _Update_ messages for post-compromise
secrecy and new participants can be added or existing participants
removed from the group.
Paragraph (version A):
The protocol algorithms we specify here follow.  Each algorithm
specifies both (i) how a participant performs the operation and (ii)
how other participants update their state based on it.
Paragraph (version A):
Before the initialization of a group, participants publish
UserInitKey objects to a directory provided to the Messaging Service.
Paragraph (version A):
When a participant A wants to establish a group with B and C, it
first downloads UserInitKeys for B and C.  It then initializes a
group state containing only itself and uses the UserInitKeys to
compute Welcome and Add messages to add B and C, in a sequence chosen
by A.  The Welcome messages are sent directly to the new members
(there is no need to send them to the group).  The Add messages are
broadcasted to the Group, and processed in sequence by B and C.
Messages received before a participant has joined the group are
ignored.  Only after A has received its Add messages back from the
server does it update its state to reflect their addition.
Paragraph (version A):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download an UserInitKey for a new participant
and broadcast an Add message that the current group can use to update
their state and the new participant can use to initialize its state.
Paragraph (version A):
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
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
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.
Paragraph (version A):
Users are removed from the group in a similar way, as an update is
effectively removing the old leaf from the group.  Any member of the
group can generate a Remove message that adds new entropy to the
group state that is known to all members except the removed member.
After other participants have processed this message, the group's
secrets will be unknown to the removed participant.  Note that this
does not necessarily imply that any member is actually allowed to
evict other members; groups can layer authentication-based access
control policies on top of these basic mechanism.
Paragraph (version B):
A long-term identity key provider which allows clients to
authenticate protocol messages in a group.  These keys MUST be
kept for the lifetime of the group as there is no mechanism in the
protocol for changing a client's identity key.
Paragraph (version B):
A directory to which clients can publish initialization keys and
download initialization keys for other participants.
Paragraph (version B):
The goal of this protocol is to allow a group of clients to exchange
confidential and authenticated messages.  It does so by deriving a
sequence of secrets and keys known only to members.  Those should be
secret against an active network adversary and should have both
forward and post-compromise secrecy with respect to compromise of a
participant.
Paragraph (version B):
We describe the information stored by each client as a _state_, which
includes both public and private data.  An initial state, including
an initial set of clients, is set up by a group creator using the
_Init_ algorithm and based on information pre-published by clients.
The creator sends the _Init_ message to the clients, who can then set
up their own group state and derive the same shared secret.  Clients
then exchange messages to produce new shared states which are
causally linked to their predecessors, forming a logical Directed
Acyclic Graph (DAG) of states.  Members can send _Update_ messages
for post-compromise secrecy and new clients can be added or existing
members removed from the group.
Paragraph (version B):
The protocol algorithms we specify here follow.  Each algorithm
specifies both (i) how a client performs the operation and (ii) how
other clients update their state based on it.
Paragraph (version B):
Before the initialization of a group, clients publish UserInitKey
objects to a directory provided to the Messaging Service.
Paragraph (version B):
When a client A wants to establish a group with B and C, it first
downloads UserInitKeys for B and C.  It then initializes a group
state containing only itself and uses the UserInitKeys to compute
Welcome and Add messages to add B and C, in a sequence chosen by A.
The Welcome messages are sent directly to the new members (there is
no need to send them to the group).  The Add messages are broadcasted
to the group, and processed in sequence by B and C.  Messages
received before a client has joined the group are ignored.  Only
after A has received its Add messages back from the server does it
update its state to reflect their addition.
Paragraph (version B):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download an UserInitKey for a new client and
broadcast an Add message that the current group can use to update
their state and the new client can use to initialize its state.
Paragraph (version B):
To enforce forward secrecy and post-compromise security of messages,
each member periodically updates its leaf secret which represents its
contribution to the group secret.  Any member of the 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 group secret with
that new information.  Once all members have processed this message,
the group's secrets will be unknown to an attacker that had
compromised the sender's prior leaf secret.
Paragraph (version B):
Members are removed from the group in a similar way, as an update is
effectively removing the old leaf from the group.  Any member of the
group can generate a Remove message that adds new entropy to the
group state that is known to all members except the removed member.
After other participants have processed this message, the group's
secrets will be unknown to the removed participant.  Note that this
does not necessarily imply that any member is actually allowed to
evict other members; groups can layer authentication-based access
control policies on top of these basic mechanism.
Paragraph (version A):
The protocol uses "ratchet trees" for deriving shared secrets among a
group of participants.
Paragraph (version A):
Trees consist of _nodes_. A node is a _leaf_ if it has no children,
and a _parent_ otherwise; note that all parents in our ratchet trees
have precisely two children, a _left_ child and a _right_ child.  A
node is the _root_ of a tree if it has no parents, and _intermediate_
if it has both children and parents.  The _descendants_ of a node are
that node, its children, and the descendants of its children, and we
say a tree _contains_ a node if that node is a descendant of the root
of the tree.  Nodes are _siblings_ if they share the same parent.
Paragraph (version B):
The protocol uses "ratchet trees" for deriving shared secrets among a
group of clients.
Paragraph (version B):
Trees consist of _nodes_. A node is a _leaf_ if it has no children,
and a _parent_ otherwise; note that all parents in our trees have
precisely two children, a _left_ child and a _right_ child.  A node
is the _root_ of a tree if it has no parents, and _intermediate_ if
it has both children and parents.  The _descendants_ of a node are
that node, its children, and the descendants of its children, and we
say a tree _contains_ a node if that node is a descendant of the root
of the tree.  Nodes are _siblings_ if they share the same parent.
Paragraph (version A):
In order to update the state of the group such as adding and removing
participants, MLS messages are used to make changes to the group's
ratchet tree.  The participant proposing an update to the tree
transmits a set of values for intermediate nodes in the direct path
of a leaf.  Other participants in the group can use these nodes to
update their view of the tree, aligning their copy of the tree to the
sender's.
Paragraph (version B):
In order to update the state of the group such as adding and removing
clients, MLS messages are used to make changes to the group's ratchet
tree.  The member proposing an update to the tree transmits a set of
values for intermediate nodes in the direct path of a leaf.  Other
members in the group can use these nodes to update their view of the
tree, aligning their copy of the tree to the sender's.
Paragraph (version A):
In order to facilitate asynchronous addition of participants to a
group, it is possible to pre-publish initialization keys that provide
some public information about a user.  UserInitKey messages provide
information about a potential group member, that a group member can
use to add this user to a group asynchronously.
Paragraph (version B):
In order to facilitate asynchronous addition of clients to a group,
it is possible to pre-publish initialization keys that provide some
public information about a user.  UserInitKey messages provide
information about a client that any existing member can use to add
this client to the group asynchronously.
Paragraph (version A):
On receipt of an Add message, new participants SHOULD send an update
immediately to their key.  This will help to limit the tree structure
degrading into subtrees, and thus maintain the protocol's efficiency.
Paragraph (version A):
An Update message is sent by a group participant to update its leaf
key pair.  This operation provides post-compromise security with
regard to the participant's prior leaf private key.
Paragraph (version B):
After processing an Add message, the new member SHOULD send an Update
immediately to update its key.  This will help to limit the tree
structure degrading into subtrees, and thus maintain the protocol's
efficiency.
Paragraph (version B):
An Update message is sent by a group member to update its leaf secret
and key pair.  This operation provides post-compromise security with
regard to the member's prior leaf private key.
Paragraph (version A):
A Remove message is sent by a group member to remove one or more
participants from the group.
Paragraph (version B):
A Remove message is sent by a group member to remove one or more
members from the group.
Paragraph (version A):
The primary purpose of the handshake protocol is to provide an
authenticated group key exchange to participants.  In order to
protect Application messages sent among those participants, the
Application secret provided by the Handshake key schedule is used to
derive encryption keys for the Message Protection Layer.
Paragraph (version A):
Application messages MUST be protected with the Authenticated-
Encryption with Associated-Data (AEAD) encryption scheme associated
with the MLS ciphersuite.  Note that "Authenticated" in this context
does not mean messages are known to be sent by a specific participant
but only from a legitimate member of the group.  To authenticate a
message from a particular member, signatures are required.  Handshake
messages MUST use asymmetric signatures to strongly authenticate the
sender of a message.
Paragraph (version A):
Each participant maintains their own chain of Application secrets,
where the first one is derived based on a secret chained from the
Epoch secret.  As shown in key-schedule, the initial Application
secret is bound to the identity of each participant to avoid
collisions and allow support for decryption of reordered messages.
Paragraph (version B):
The primary purpose of the handshake protocol is to provide an
authenticated group key exchange to clients.  In order to protect
Application messages sent among those members of a group, the
Application secret provided by the Handshake key schedule is used to
derive encryption keys for the Message Protection Layer.
Paragraph (version B):
Application messages MUST be protected with the Authenticated-
Encryption with Associated-Data (AEAD) encryption scheme associated
with the MLS ciphersuite.  Note that "Authenticated" in this context
does not mean messages are known to be sent by a specific client but
only from a legitimate member of the group.  To authenticate a
message from a particular member, signatures are required.  Handshake
messages MUST use asymmetric signatures to strongly authenticate the
sender of a message.
Paragraph (version B):
Each member maintains their own chain of Application secrets, where
the first one is derived based on a secret chained from the Epoch
secret.  As shown in key-schedule, the initial Application secret is
bound to the identity of each client to avoid collisions and allow
support for decryption of reordered messages.
Paragraph (version A):
Senders MUST only use the Application Secret once and
monotonically increment the generation of their secret.  This is
important to provide Forward Secrecy at the level of Application
messages.  An attacker getting hold of a Participant's Application
Secret at generation [N+1] will not be able to derive the
Participant's Application Secret [N] nor the associated AEAD key
and nonce.
Paragraph (version B):
Senders MUST only use the Application Secret once and
monotonically increment the generation of their secret.  This is
important to provide Forward Secrecy at the level of Application
messages.  An attacker getting hold of a member specific
Application Secret at generation [N+1] will not be able to derive
the member's Application Secret [N] nor the associated AEAD key
and nonce.
Paragraph (version A):
The Group identifier and epoch allow a device to know which Group
secrets should be used and from which Epoch secret to start computing
other secrets and keys.  The participant identifier is used to derive
the participant Application secret chain from the initial shared
Application secret.  The application generation field is used to
determine which Application secret should be used from the chain to
compute the correct AEAD keys before performing decryption.
Paragraph (version A):
The signature used in the ApplicationMessageContent is computed over
the SignatureContent which covers the metadata information about the
current state of the group (group identifier, epoch, generation and
sender's Leaf index) to prevent Group participants from impersonating
other participants.  It is also necessary in order to prevent cross-
group attacks.
Paragraph (version B):
The group identifier and epoch allow a device to know which group
secrets should be used and from which Epoch secret to start computing
other secrets and keys.  The sender identifier is used to derive the
member's Application secret chain from the initial group Application
secret.  The application generation field is used to determine which
Application secret should be used from the chain to compute the
correct AEAD keys before performing decryption.
Paragraph (version B):
The signature used in the ApplicationMessageContent is computed over
the SignatureContent which covers the metadata information about the
current state of the group (group identifier, epoch, generation and
sender's Leaf index) to prevent group members from impersonating
other clients.  It is also necessary in order to prevent cross-group
attacks.
Paragraph (version A):
Since each Application message contains the Group identifier, the
epoch and a message counter, a participant can receive messages out
of order.  If they are able to retrieve or recompute the correct AEAD
decryption key from currently stored cryptographic material
participants can decrypt these messages.
Paragraph (version A):
For usability, MLS Participants might be required to keep the AEAD
key and nonce for a certain amount of time to retain the ability to
decrypt delayed or out of order messages, possibly still in transit
while a decryption is being done.
Paragraph (version B):
Since each Application message contains the group identifier, the
epoch and a message counter, a client can receive messages out of
order.  If they are able to retrieve or recompute the correct AEAD
decryption key from currently stored cryptographic material clients
can decrypt these messages.
Paragraph (version B):
For usability, MLS clients might be required to keep the AEAD key and
nonce for a certain amount of time to retain the ability to decrypt
delayed or out of order messages, possibly still in transit while a
decryption is being done.
Paragraph (version A):
Note that the long-term identity keys used by the protocol MUST be
distributed by an "honest" authentication service for parties to
authenticate their legitimate peers.
Paragraph (version B):
Note that the long-term identity keys used by the protocol MUST be
distributed by an "honest" authentication service for clients to
authenticate their legitimate peers.
Paragraph (version A):
There are two forms of authentication we consider.  The first form
considers authentication with respect to the group.  That is, the
group members can verify that a message originated from one of the
members of the group.  This is implicitly guaranteed by the secrecy
of the shared key derived from the ratcheting trees: if all members
of the group are honest, then the shared group key is only known to
the group members.  By using AEAD or appropriate MAC with this shared
key, we can guarantee that a participant in the group (who knows the
shared secret key) has sent a message.
Paragraph (version B):
There are two forms of authentication we consider.  The first form
considers authentication with respect to the group.  That is, the
group members can verify that a message originated from one of the
members of the group.  This is implicitly guaranteed by the secrecy
of the shared key derived from the ratcheting trees: if all members
of the group are honest, then the shared group key is only known to
the group members.  By using AEAD or appropriate MAC with this shared
key, we can guarantee that a member in the group (who knows the
shared secret key) has sent a message.