Draft: draft-ietf-mls-protocol

Commentary:  sent me some late comments , which I have reflected in this PR . The most significant changes are : A new section in the overview covering external commits , so that that concept has been introduced before it is encountered further down . A new subsection in the security considerations elaborating why key uniqueness mattes , and some slightly stronger requirements around it in the appropriate spots . 
 Looks good modulo the existing suggestions and comments
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 member to send messages to the
group encrypted with their own sender key.  On the one hand, using
sender keys improves efficiency relative to pairwise broadcast of
individual messages, and it provides forward secrecy (with the
addition of a hash ratchet).  On the other hand, it is difficult to
achieve post-compromise security with sender keys, requiring a number
of key update messages that scales as the square of the group size.
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 B):
For a group of size greater than two, a common strategy is to
distribute symmetric "sender keys" over existing 1:1 secure channels,
and then for each member to send messages to the group encrypted with
their own sender key.  On the one hand, using sender keys improves
efficiency relative to pairwise transmission of individual messages,
and it provides forward secrecy (with the addition of a hash
ratchet).  On the other hand, it is difficult to achieve post-
compromise security with sender keys, requiring a number of key
update messages that scales as the square of the group size.  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 object that summarizes the state of the group.  The group
context is signed to bind a message to a particular group, and
also provided to new members to help them join a group.
Paragraph (version B):
An object that summarizes the shared, public state of the group.
The group context is typically distributed in a signed GroupInfo
message, which is provided to new members to help them join a
group.
Paragraph (version A):
A _resumption secret_ that members can use to prove their
membership in the group, e.g., in the case of branching a
subgroup.
Paragraph (version B):
A _resumption secret_ that members can use to prove their
membership in the group, e.g., when creating a subgroup or a
successor group.
Paragraph (version A):
Update messages SHOULD be sent at regular intervals of time as long
as the group is active, and members that don't update SHOULD
eventually be removed from the group.  It's left to the application
to determine an appropriate amount of time between Updates.  Since
the purpose of sending an Update is to proactively constrain a
compromise window, the right frequency is usually on the order of
hours or days, not milliseconds.
Paragraph (version B):
Update messages SHOULD be sent at regular intervals of time as long
as the group is active, and members that don't update SHOULD
eventually be removed from the group.  It's left to the application
to determine an appropriate amount of time between Updates.  Since
the purpose of sending an Update is to proactively constrain a
compromise window, the right frequency is usually on the order of
hours or days, not milliseconds.  For example, an application might
send an Update each time a member sends an application message after
receiving from other members, or daily if no application messages are
sent.
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):
Welcome messages don't necessarily need to be sent directly to new
joiners.  Since they are encrypted to new joiners, they could be
distributed more broadly, say if the application only had access
to a broadcast channel for the group.
Paragraph (version B):
Proposal messages don't need to be immediately sent to all group
members.  They need to be available to the committer before
generating a commit, and to other members before processing the
commit.
Paragraph (version B):
The sender of a Commit doesn't necessarily have to wait to receive
its own Commit back before advancing its state.  It only needs to
know that its Commit will be the next one applied by the group,
say based on a promise from an orchestration server.
Paragraph (version B):
In addition to the Welcome-based flow for adding a new member to the
group, it is also possible for a new member to join by means of an
"external Commit".  This mechanism can be used when the existing
members don't have a KeyPackage for the new member, for example, in
the case of an "open" group that can be joined by new members without
asking permission from existing members.
Paragraph (version B):
groupinfo-flow shows a typical message flow for an external join.  To
enable a new member to join the group in this way, a member of the
group (A, B) publishes a GroupInfo object that includes the
GroupContext for the group as well as a public key that can be used
to encrypt a secret to the existing members of the group.  When the
new member Z wishes to join, they download the GroupInfo object and
use it to form a Commit of a special form that adds Z to the group
(as detailed in joining-via-external-commits).  The existing members
of the group process this external Commit in a similar way to a
normal Commit, advancing to a new epoch in which Z is now a member of
the group.
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.  A group member that wishes to inject a PSK
issues a PreSharedKey proposal (presharedkey) describing the PSK to
be injected.  When this proposal is committed, the corresponding PSK
will be incorporated into the key schedule as described in pre-
shared-keys.
Paragraph (version B):
Linking epochs in this way 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):
As described in views, different members know different subsets of
the set of private keys corresponding to the public keys in nodes in
the tree.  The private key corresponding to a parent node is known
only to members at leaf nodes that are descedants of that node.  The
private key corresponding to a leaf node is known only to the member
at that leaf node.  A leaf node is _unmerged_ relative to one of its
ancestor nodes if the member at the leaf node does not know the
private key corresponding to the ancestor node.
Paragraph (version A):
The reverse implication is not true: A member may not know the
private keys of all the intermediate nodes above them.  Such a member
has an _unmerged_ leaf.  Encrypting to an intermediate node requires
encrypting to the node's public key, as well as the public keys of
all the unmerged leaves below it.  A leaf is unmerged when it is
first added, because the process of adding the leaf does not give it
access to all of the nodes above it in the tree.  Leaves are "merged"
as they receive the private keys for nodes, as described in ratchet-
tree-evolution.
Paragraph (version B):
The reverse implication is not true: A member may not know the
private key of an intermediate node above them.  Such a member has an
_unmerged_ leaf at the intermediate node.  Encrypting to an
intermediate node requires encrypting to the node's public key, as
well as the public keys of all the unmerged leaves below it.  A leaf
is unmerged with regard to all of its ancestors when it is first
added, because the process of adding the leaf does not give it access
to the private keys for all of the nodes above it in the tree.
Leaves are "merged" as they receive the private keys for nodes, as
described in ratchet-tree-evolution.
Paragraph (version A):
The signature algorithm specified in the ciphersuite is the mandatory
algorithm to be used for signatures in FramedContentAuthData and the
tree signatures.  It MUST be the same as the signature algorithm
specified in the credentials in the leaves of the tree (including the
leaf node information in KeyPackages used to add new members).
Paragraph (version B):
The signature algorithm specified in a group's ciphersuite is the
mandatory algorithm to be used for signing messages within the group.
It MUST be the same as the signature algorithm specified in the
credentials in the leaves of the tree (including the leaf node
information in KeyPackages used to add new members).
Paragraph (version B):
Verify that none of the public keys in the UpdatePath appear in
any node of the new ratchet tree.
Paragraph (version B):
Verify that the encryption key in the parent node does not
appear in any other node of the tree.
Paragraph (version B):
The encryption and signature keys stored in the "encryption_key" and
"signature_key" fields of ratchet tree nodes MUST be distinct from
one another.  If two members' leaf nodes have the same signature key,
for example, then the data origin authentication properties afforded
by signatures within the group are degraded.
Paragraph (version B):
Uniqueness of keys in leaf nodes is assured by explicit checks on
leaf nodes being added to the tree by Add or Update proposals, or in
the "path" field of a Commit.  Details can be found in leaf-node-
validation, proposal-list-validation, and processing-a-commit.
Uniqueness of encryption keys in parent nodes is assured by checking
that the keys in an UpdatePath are not found elsewhere in the tree
(see processing-a-commit.