Draft: draft-barnes-mls-protocol

Commentary: This PR adds a pretty complete description of the protocol . The only major thing that 's missing is , which should be straightforward - ish to construct . want to take a stab at that ?
Paragraph (version B):
Since a group can evolve over time, a session logically comprises a
sequence of states.  The time in which each individual state is used
is called an "epoch", and each state is assigned an epoch number that
increments when the state changes.
Paragraph (version B):
MLS handshake message provide each node with enough information about
the trees to authenticate messages within the group and compute the
group secrets.
Paragraph (version B):
Public keys used in the protocol are opaque values in a format
defined by the ciphersuite.
Paragraph (version B):
The derivation of the epoch key pair depends on the change being
made.  For the first epoch, when there is no previous epoch key pair,
the creator of the group generates a fresh key pair and publishes it
to the initial set of participants.
Paragraph (version B):
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 or group.  UserInitKey messages
provide information a user that a group member can use to add the
user to a group without the user being online.  GroupInitKey messages
provide information about a group that a new user can use to join the
group without any of the existing members of the group being online.
Paragraph (version B):
A UserInitKey object specifies what cipher suites a client supports,
as well as providing public keys that the client can use for key
derivation and signing.  The client's identity key is intended to be
stable through the lifetime of the group; there is no mechanism to
change it.  Init keys are intend to be used one time only (or perhaps
a small number of times, see #init-key-reuse).
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 defined by the corresponding entry in the cipher_suites
array.
Paragraph (version B):
The whole structure is signed using the client's identity key.  A
UserInitKey object with an invalid signature field MUST be considered
mal-formed.  The input to the signature computation comprises all of
the fields except for the signture field.
Paragraph (version B):
A GroupInitKey object specifies the aspects of a group's state that a
new member needs to initialize its state (together with an identity
key and a fresh leaf key pair).
Paragraph (version B):
GroupInitKey messages are not themselves signed.  A GroupInitKey
should not be published "bare"; instead, it should be published by
constructing a handshake message with type "none", which will include
a signature by a member of the group and a proof of membership in the
group.
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.
Paragraph (version B):
An MLS handshake message encapsulates a specific message that
accomplishes a change in group state, and also includes two other
important features: First, it provides a GroupInitKey so that a new
participant can observe the latest state of the handshake and
initialize itself.  Second, it provides a signature by a member of
the group, together with a Merle inclusion proof that demonstrates
that the signer is a legitimate member of the group.
Paragraph (version B):
Before considering a handshake message valid, the recipient MUST
verify both that the signature is valid and that the Merkle inclusion
proof is valid.  The input to the signature computations comprises
the entire handshake message except for the signature field.
Paragraph (version B):
The Merkle tree head to be used for validating the inclusion proof
MUST be one that the recipient trusts to represent the current list
of participant identity keys.
Paragraph (version B):
An GroupAdd message is sent by a group member to add a new
participant to the group.  The contents of the message are simply the
UserInitKey for the user being added.
Paragraph (version B):
The update secret resulting from this change is the output of a DH
computation between the private key for the root of the ratchet tree
and the add public key from the previous epoch.
Paragraph (version B):
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):
Compute the direct path from the new participant's leaf in the new
ratchet tree (the add_path).
Paragraph (version B):
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):
A delete message is sent by a group member to remove one or more
participants from the group.
Paragraph (version B):
The head field in the Delete message holds the public keys
corresponding to the subtree heads.  The path field holds the public
keys corresponding to the delete path, with the last element omitted
(it is unnecessary).  As a result, the heads and path arrays MUST
have the same length.
Paragraph (version B):
Note that the sender of a Delete message must enough information
about the ratchet tree so that it has all of the subtree heads
resulting from the puncture operation.  This criterion is met if the
sender has a copath for each of the deleted participants.
Paragraph (version B):
The update secret for this change is the last DH output from the
delete path.
Paragraph (version A):
The Asynchronous Ratcheting Tree is the building block around which
this protocol is built.  It was originally specified by Cohn-Gordon
et al with a formal proof of its security properties
(https://eprint.iacr.org/2017/666).
Paragraph (version A):
ART uses a Diffie-Hellman Key Tree to derive a shared secret for a
group, allowing it to be efficiently updated (ratcheted) by any group
member (leaf node) to provide the properties of Forward Secrecy and
Post-Compromise Security.  Alongside ratcheting, receiving messages,
and changing the group membership can also be efficiently achieved.
Paragraph (version A):
The ART root secret is the private Diffie-Hellman key of the root of
the tree.  This should not be used directly within the protocol, but
rather computed into a Stage Key (TODO: below).
Paragraph (version A):
For this document, we will use the shorthand notation [A,B] to
indicate KDF(DH(Alice, Bob)).
Paragraph (version A):
Changing a leaf DH key will inherently update its entire path to and
including the root.
Paragraph (version A):
In the above tree, if C updates to C', the path of all nodes
referencing C is updated, resulting in the below tree.
Paragraph (version A):
C must transmit the public keys of her entire path to the other
participants in the tree.  Each participant will update their copath
with their respective element from this path, and thus recompute the
same updated tree that C has computed.
Paragraph (version A):
Leaves are never removed from tree.  One endpoint can remove another
endpoint by updating that endpoint's leaf to a key that the endpoint
being removed does not possess.
Paragraph (version A):
At any point, an endpoint can publish a PreKey message, which
contains information that another endpoint can use to add that
endpoint to a group.  Typically applications provide a PreKey cache
to which endpoints periodically push fresh PreKey messages.
Paragraph (version A):
Suppose an endpoint A wants to initiate a group conversation with
otehr endpoints B, C, and D.  A accomplishes this by downloading
PreKeys fro B, C, and D, computing a tree over (A, B, C, D), and
sending different individual Setup messages to B, C, and D.
Paragraph (version A):
If A subsequently wants to add another endpoint E to the
conversation, then the process is similar.  First A downloads a
PreKey for E and uses it to add E to the tree.  From these
computations, A generates a Setup message for E and an Add message
that can be broadcast to B, C, and D.
Paragraph (version A):
Upon being added, E should update its leaf key so that its leaf key
will not be known to A.  To update a leaf key in the tree, an
endpoint simply generates a new key pair, creates an Update message,
and broadcasts it to the group.
Paragraph (version A):
MLS messages synchronize this state information across the
participants in the group.
Paragraph (version A):
Note that no state is modified when an endpoint sends a Setup, Add,
or Update message.  Because all endpoints need to process updates to
the tree in the same order, there is a risk that any given message of
these types will be rejected.  To avoid the need to roll back on such
rejections, endpoints only apply Setup / Add / Update messages once
they are published and accepted by the group.  For more discussion of
how modifications to the tree should be sequenced, see #sequencing-
of-modifications.