Draft: draft-ietf-mls-protocol

Commentary: Some of these editorial comments I find less clear than the original . The code changes and varint are fine . Could you please split this into two more atomic PRs so we can discuss separately ? 
 Feel free to leave comments on the editorial portion of this PR to keep things moving
Paragraph (version A):
The core organizing principles of MLS are _groups_ and _epochs_.  A
group represents a logical collection of clients that share a common
secret value at any given time.  The history of a group is divided
into a linear sequence of epochs.  In each epoch, a set of
authenticated _members_ agree on an _epoch secret_ that is known only
to the members of the group in that epoch.  The set of members
involved in the group can change from one epoch to the next, and MLS
ensures that only the members in the current epoch have access to the
epoch secret.  From the epoch secret, members derive further shared
secrets for message encryption, group membership authentication, etc.
Paragraph (version B):
The core organizing principles of MLS are _groups_ and _epochs_.  A
group represents a logical collection of clients that share a common
secret value at any given time.  The history of a group is divided
into a linear sequence of epochs.  In each epoch, a set of
authenticated _members_ agree on an _epoch secret_ that is known only
to the members of the group in that epoch.  The set of members
involved in the group can change from one epoch to the next, and MLS
ensures that only the members in the current epoch have access to the
epoch secret.  From the epoch secret, members derive further shared
secrets for message encryption, group membership authentication, and
so on.
Paragraph (version A):
A _key schedule_ that describes the chain of key derivations used
to progress from epoch to epoch (mainly using the _init_secret_
and _epoch_secret_); and to derive a variety of other secrets (see
epoch-derived-secrets) used during the current epoch.  One of
these (the _encryption_secret_) is the root of _secret_tree_.
Paragraph (version A):
A _secret tree_ derived from the key schedule that represents
shared secrets used by the members of the group to provide
confidentiality and forward secrecy for MLS messages.  Each epoch
has a distinct secret tree.
Paragraph (version A):
Each member of the group maintains a view of these facets of the
group's state.  MLS messages are used to initialize these views and
keep them in sync as the group transitions between epochs.
Paragraph (version A):
Each new epoch is initiated with a Commit message.  The Commit
instructs existing members of the group to update their views of the
ratchet tree by applying a set of Proposals, and uses the updated
ratchet tree to distribute fresh entropy to the group.  This fresh
entropy is provided only to members in the new epoch, not to members
who have been removed, so it maintains the confidentiality of the
epoch secret (in other words, it provides post-compromise security
with respect to those members).
Paragraph (version A):
For each Commit that adds member(s) to the group, there is a single
corresponding Welcome message.  The Welcome message provides all the
new members with the information they need to initialize their views
of the key schedule and ratchet tree, so that these views are
equivalent to the views held by other members of the group in this
epoch.
Paragraph (version A):
An _encryption secret_ that is used to initialize the secret tree
for the epoch.
Paragraph (version A):
A _confirmation key_ that is used to confirm that all members
agree on the shared state of the group.
Paragraph (version A):
Finally, an _init secret_ is derived that is used to initialize the
next epoch.
Paragraph (version B):
An _encryption secret_ that is used to initialize the secret
tree for the epoch.
Paragraph (version B):
An _exporter secret_ that allows other protocols to leverage
MLS as a generic authenticated group key exchange.
Paragraph (version B):
A _secret tree_ derived from the key schedule that represents
shared secrets used by the members of the group for encrypting and
authenticating messages.  Each epoch has a distinct secret tree.
Paragraph (version B):
Each member of the group maintains a partial view of these components
of the group's state.  MLS messages are used to initialize these
views and keep them in sync as the group transitions between epochs.
Paragraph (version B):
Each new epoch is initiated with a Commit message.  The Commit
instructs existing members of the group to update their views of the
ratchet tree by applying a set of Proposals, and uses the updated
ratchet tree to distribute fresh entropy to the group.  This fresh
entropy is provided only to members in the new epoch and not to
members who have been removed.  Commits thus maintain the property
that the the epoch secret is confidential to the members in the
current epoch.
Paragraph (version B):
For each Commit that adds one or more members to the group, there is
a single corresponding Welcome message.  The Welcome message provides
all the new members with the information they need to initialize
their views of the key schedule and ratchet tree, so that these views
align with the views held by other members of the group in this
epoch.
Paragraph (version A):
Members are removed from the group in a similar way.  Any member of
the group can send a Remove proposal followed by a Commit message.
The Commit message provides new entropy to all members of the group
except the removed member.  This new entropy is added to the epoch
secret for the new epoch, so that it is not known to the removed
member.  Note that this does not necessarily imply that any member is
actually allowed to evict other members; groups can enforce access
control policies on top of these basic mechanism.
Paragraph (version B):
Members are removed from the group in a similar way.  Any member of
the group can send a Remove proposal followed by a Commit message.
The Commit message provides new entropy to all members of the group
except the removed member.  This new entropy is added to the epoch
secret for the new epoch so that it is not known to the removed
member.  Note that this does not necessarily imply that any member is
actually allowed to evict other members; groups can enforce access
control policies on top of these basic mechanism.
Paragraph (version A):
A group has a single linear sequence of epochs.  Groups and epochs
are generally independent of one-another.  However, it can sometimes
be useful to link epochs cryptographically, either within a group or
across groups.  MLS derives a resumption pre-shared key (PSK) from
each epoch to allow entropy extracted from one epoch to be injected
into a future epoch.  This link guarantees that members entering the
new epoch agree on a key if and only if they were members of the
group during the epoch from which the resumption key was extracted.
Paragraph (version B):
A group has a single linear sequence of epochs.  Groups and epochs
are generally independent of one another.  However, it can sometimes
be useful to link epochs cryptographically, either within a group or
across groups.  MLS derives a resumption pre-shared key (PSK) from
each epoch to allow entropy extracted from one epoch to be injected
into a future epoch.  This link guarantees that members entering the
new epoch agree on a key if and only if they were members of the
group during the epoch from which the resumption key was extracted.