Draft: draft-ietf-mls-protocol

Commentary: There was agreement at the MLS interim of September 2018 to focus further development on TreeKEM , not ART . This PR implements that change . 
 Thanks for the reviews , and
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.  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 B):
In this document, we describe a protocol based on tree structures
that enable asynchronous group keying with forward secrecy and post-
compromise security.  Based on earlier work on "asynchronous
ratcheting trees" art, the mechanism presented here use a
asynchronous key-encapsulation mechanism for tree structures.  This
mechanism allows the members of the group to derive and update shared
keys with costs that scale as the log of the group size.
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 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 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 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.  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 A):
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 are constructed as left-balanced trees, defined such
that each parent node's key pair is derived from the Diffie-Hellman
shared secret of its two child nodes.  To compute the root secret and
private key, a participant must know the public keys of nodes in its
copath, as well as its own leaf private key.
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.  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 A):
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 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.  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):
To perform an update, 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):
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 A):
Note that in TreeKEM, the length of the "node\_secrets" vector MUST
be exactly one less than the length of the "nodes" vector, since the
secret value for the leaf node is not encrypted.  For "i > 0",
"node_secrets[i-1]" has the encrypted node secret corresponding to
the public key in "nodes[i]".
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.
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):
The length of the "node\_secrets" vector MUST be zero for the first
node in the path and one for all other nodes in the path.
Paragraph (version A):
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 A):
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
removes.
Paragraph (version B):
As long as handshake messages cannot be merged, 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):
It might be possible, because of the non-contributivity of
intermediate nodes, that update messages could be applied one after
the other without the Delivery Service having to reject any handshake
message, which would make MLS 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 removes.
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.  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):
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 A):
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):
It is possible in principle 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, updates
can be merged by recipients as long as the recipients agree on an
order - the only question is which node was last updated.