Draft: draft-ietf-mls-protocol

Commentary: Changes ( apart from editorial ): Remove the text about the key schedule . Reason : I found the text confusing , because updating paths provides FS and PCS for the HPKE keys in the ratchet tree , and not directly for the key schedule . Generate the leaf key pair simply as a fresh HPKE key pair , and not from the leafsecret . I could n't see any benefit of using the leafsecret . I wonder if there is a good reason ? 
 I am concerned that we are asking for a LOT of fresh entropy if ( in addition to nonces ) we need a crypto - random value every epoch for every group ( a Wire client can easily a member of thousands of groups at a time ) . Do you have a concern about deriving it ? 
 Discussion on the virtual interim : To concern : This allows the base path secret to be derived , e.g. , using a KDF , so this does n't necessarily increase the amount of entropy needed Clear to merge
Paragraph (version A):
The ratchet tree for an epoch describes the membership of a group in
that epoch, providing public-key encryption keys that can be used to
encrypt to subsets of the group as well as information to
authenticate the members.  In order to reflect changes to the
membership of the group from one epoch to the next, corresponding
changes are made to the ratchet tree.  In this section, we describe
the content of the tree and the required operations.
Paragraph (version B):
The ratchet tree for an epoch describes the membership of a group in
that epoch, providing public-key encryption (HPKE) keys that can be
used to encrypt to subsets of the group as well as information to
authenticate the members.  In order to reflect changes to the
membership of the group from one epoch to the next, corresponding
changes are made to the ratchet tree.  In this section, we describe
the content of the tree and the required operations.
Paragraph (version A):
A member of an MLS group advances the key schedule to provide forward
secrecy and post-compromise security by providing the group with
fresh key material to be added into the group's shared secret.  To do
so, one member of the group generates fresh key material, applies it
to their local tree state, and then sends this key material to other
members in the group via an UpdatePath message (see update-paths) .
All other group members then apply the key material in the UpdatePath
to their own local tree state to derive the group's now-updated
shared secret.
Paragraph (version A):
To begin, the generator of the UpdatePath updates its leaf node and
its direct path to the root with new secret values.  The HPKE leaf
public key within the KeyPackage MUST be derived from a freshly
generated HPKE secret key to provide post-compromise security.
Paragraph (version A):
The generator of the UpdatePath starts by sampling a fresh random
value called "leaf_secret", and uses the leaf_secret to generate
their leaf HPKE key pair (see key-packages) and to seed a sequence of
"path secrets", one for each ancestor of its leaf.  In this setting,
path_secret[0] refers to the leaf's parent, path_secret[1] to the
parent's parent, and so on.  At each step, the path secret is used to
derive a new secret value for the corresponding node, from which the
node's key pair is derived.
Paragraph (version B):
In order to provide forward secrecy and post-compromise security,
whenever a member initiates an epoch change (i.e., commits; see
commit), they refresh all HPKE key pairs in the ratchet tree for
which they know the secret keys.  More precisely, they refresh the
key pairs of their leaf and of all nodes on their leaf's direct path.
Paragraph (version B):
The member initiating the epoch change generates the fresh key pairs
using the following procedure.  The procedure is designed in a way
that allows group members to efficiently communicate the fresh secret
keys to other group members, as described in update-paths.
Paragraph (version B):
Generate a fresh HPKE key pair for the leaf.
Paragraph (version B):
Generate a sequence of path secrets, one for each node on the
leaf's direct path as follows.  In this context, "path_secret[0]"
is generated for the leaf's parent, "path_secret[1]" is generated
for the leaf's grandparent, etc.
Paragraph (version B):
Compute the sequence of HPKE key pairs "(node_priv,node_pub)", one
for each node on the leaf's direct path, as follows.
Paragraph (version A):
After performing these operations, the generator of the UpdatePath
MUST delete the leaf_secret.