Draft: draft-barnes-mls-protocol

Commentary: This PR contains several changes that I just wanted to get in for the IETF 102 deadline . Add TreeKEM as an option ( leveraging some Beurdouche work )   to always do " simulated UserAdd " Delete -Remove
Paragraph (version A):
In this document, we describe a protocol based on tree structures
that enable asynchronous group keying with forward secrecy and post-
compromise security.  The use of "asynchronous ratcheting trees" art
allows the members of the group to derive and update shared keys with
costs that scale as the log of the group size.  The use of Merkle
trees to store identity information allows strong authentication of
group membership, again with logarithmic cost.
Paragraph (version B):
In this document, we describe a protocol based on tree structures
that enable asynchronous group keying with forward secrecy and post-
compromise security.  This document describes two candidate
approaches, one using "asynchronous ratcheting trees" art, the other
using an asynchronous key-encapsulation mechanism for tree structures
called TreeKEM.  Both mechanisms allow the members of the group to
derive and update shared keys with costs that scale as the log of the
group size.  The use of Merkle trees to store identity information
allows strong authentication of group membership, again with
logarithmic cost.
Paragraph (version A):
To enforce forward secrecy and post-compromise security of messages,
each participant periodically updates its leaf key, the DH key pair
that represents its contribution to the group key.  Any member of the
group can send an Update at any time by generating a fresh leaf key
pair and sending an Update message that describes how to update the
group key with that new key pair.  Once all participants have
processed this message, the group's secrets will be unknown to an
attacker that had compromised the sender's prior DH leaf private key.
Paragraph (version B):
To enforce forward secrecy and post-compromise security of messages,
each participant periodically updates its leaf key, the DH key pair
that represents its contribution to the group key.  Any member of the
group can send an Update at any time by generating a fresh leaf key
pair and sending an Update message that describes how to update the
group key with that new key pair.  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 private key.
Paragraph (version A):
Asynchronous ratcheting trees for deriving shared secrets among
this group of participants.
Paragraph (version B):
Ratchet trees for deriving shared secrets among this group of
participants.
Paragraph (version A):
Trees consist of various different types of _nodes_. A node is a
_leaf_ if it has no children, and a _parent_ otherwise; note that all
parents in our Merkle or asynchronous ratcheting 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):
Trees consist of various different types of _nodes_. A node is a
_leaf_ if it has no children, and a _parent_ otherwise; note that all
parents in our Merkle or 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 A):
Ratchet trees are used for generating shared group secrets.  These
are constructed as a series of Diffie-Hellman keys in a binary tree
arrangement, with each user knowing their direct path, and thus being
able to compute the shared root secret.
Paragraph (version B):
Ratchet trees are used for generating shared group secrets.  In this
section, we describe the structure of a ratchet tree, along with two
ways to manage a ratchet tree, called ART and TreeKEM.
Paragraph (version B):
The private key and public key for a node are derived from its secret
value using the Derive-Key-Pair operation.
Paragraph (version B):
The relationships between nodes are different for ART and TreeKEM.
In either case, the ratchet tree structure ensures the following
property: A party can compute the secret value for the root of the
tree if and only if that party holds the secret value for another
node lower in the tree (together with public information).  Each
participant holds one leaf secret; each participant can update the
root secret by changing their leaf secret.
Paragraph (version A):
Ratchet trees constructed this way provide the property that one must
hold at least one private key from the tree to compute the secret
root key.  With all participants holding one leaf private key; this
allows any individual to update their own key and change the shared
root key, such that only group members can compute the new key.
Paragraph (version B):
If the first participant subsequently changes its leaf secret to be
X, then the tree will have the following structure.
Paragraph (version B):
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.  While the details of update processing differ between
ART and TreeKEM (as described below), in both cases the participant
proposing an update to the tree transmits a representation of a set
of tree nodes along the direct path from a leaf to the root.  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 TreeKEM, the sender transmits a node by sending the public key for
the node and an encrypted version of the secret value for the node.
The secret value is encrypted in such a way that it can be decrypted
only by holders of the private key for one of its children, namely
the child that is not in the direct path being transmitted.  (That
is, each node in the direct path is encrypted for holders of the
private key for a node in the corresponding copath.)  For leaf nodes,
no encrypted secret is transmitted.
Paragraph (version A):
The ciphersuite must also specify an algorithm "Derive-Key-Pair" that
maps octet strings with the same length as the output of the hash
function to key pairs for the Diffie-Hellman group.
Paragraph (version B):
The ciphersuite must also specify an algorithm "Derive-Key-Pair" that
maps octet strings with the same length as the output of the hash
function to key pairs for the asymmetric encryption scheme.
Paragraph (version B):
As described in ratchet-tree-updates, each MLS message needs to
transmit node values along the direct path from a leaf to the root.
In ART, this simply entails sending the public key for each node.  In
TreeKEM, the path contains a public key for the leaf node, and a
public key and encrypted secret value for intermediate nodes in the
path.  In both cases, the path is ordered from the leaf to the root;
each node MUST be the parent of its predecessor.
Paragraph (version B):
Decryption is performed in the corresponding way, using the private
key of the non-updated child and the ephemeral public key transmitted
in the message.
Paragraph (version A):
The init_keys array MUST have the same length as the cipher_suites
array, and each entry in the init_keys array MUST be a public key for
the DH group defined by the corresponding entry in the cipher_suites
array.
Paragraph (version B):
The init_keys array MUST have the same length as the cipher_suites
array, and each entry in the init_keys array MUST be a public key for
the DH group or KEM defined by the corresponding entry in the
cipher_suites array.
Paragraph (version A):
In MLS, these changes are accomplished by broadcasting "handshake"
messages to the group.  Note that unlike TLS and DTLS, there is not a
consolidated handshake phase to the protocol.  Rather, handshake
messages are exchanged throughout the lifetime of a group, whenever a
change is made to the group state.
Paragraph (version B):
In MLS, these changes are accomplished by broadcasting "handshake"
messages to the group.  Note that unlike TLS and DTLS, there is not a
consolidated handshake phase to the protocol.  Rather, handshake
messages are exchanged throughout the lifetime of a group, whenever a
change is made to the group state.  This means an unbounded number of
interleaved application and handshake messages.
Paragraph (version A):
A GroupAdd message is sent by a group member to add a new participant
to the group.  The content of the message is only the UserInitKey for
the user being added.
Paragraph (version B):
A GroupAdd message is sent by a group member to add a new participant
to the group.
Paragraph (version B):
The public key of the ephemeral key pair is placed in the "ephemeral"
field of the GroupAdd message.  The computed direct path is placed in
the "add_path" field.
Paragraph (version A):
A UserAdd message is sent by a new group participant to add
themselves to the group, based on having already had access to a
GroupInitKey for the group.
Paragraph (version B):
A UserAdd message is sent by a new group participant to add themself
to the group, based on having already had access to a GroupInitKey
for the group.
Paragraph (version A):
A delete 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
participants from the group.
Paragraph (version A):
In either case, there is a risk of starvation.  In a sufficiently
busy group, a given member may never be able to send a handshake
message, because he always loses to other members.  The degree to
which this is a practical problem will depend on the dynamics of the
application.
Paragraph (version B):
In ART, in either case, there is a risk of starvation.  In a
sufficiently busy group, a given member may never be able to send a
handshake message, because he always loses to other members.  The
degree to which this is a practical problem will depend on the
dynamics of the application.
Paragraph (version B):
In TreeKEM, because of the non-contributivity of intermediate nodes
update messages can be applied one after the other without the
Delivery Service having to reject any handshake message which makes
TreeKEM more resilient regarding the concurrency of handshake
messages.  The Messaging system can decide to choose the order for
applying the state changes.  Note that there are certain cases (if no
total ordering is applied by the Delivery Service) where the ordering
is important for security, ie. all updates must be executed before
deletes.
Paragraph (version A):
Messages should have a counter field sent in clear-text that can be
checked by the server and used for tie-breaking.  The counter starts
at 0 and is incremented for every new incoming message.  If two group
members send a message with the same counter, the first message to
arrive will be accepted by the server and the second one will be
rejected.  The rejected message needs to be sent again with the
correct counter number.
Paragraph (version B):
Messages should have a counter field sent in clear-text that can be
checked by the server and used for tie-breaking.  The counter starts
at 0 and is incremented for every new incoming message.  In ART, if
two group members send a message with the same counter, the first
message to arrive will be accepted by the server and the second one
will be rejected.  The rejected message needs to be sent again with
the correct counter number.  In TreeKEM, the message does not
necessarily need to be resent.
Paragraph (version B):
When TreeKEM is in use, it is possible to partly address the problem
of concurrent changes by having the recipients of the changes merge
them, rather than having the senders retry.  Because the value of
intermediate node is determined by its last updated child (as opposed
to both its children in ART), TreeKEM updates can be merged by
recipients as long as the recipients agree on an order - the only
question is which node was last updated.
Paragraph (version B):
To merge an ordered list of updates, a recipient simply performs
these updates in the specified order.