Draft: draft-ietf-mls-protocol

Commentary: This PR updates two sections to reference generating and sending an message , as not all Commits transmit fresh key material ( as discussed in ) . This PR also includes light editorial edits for clarity and adds detail around the steps to perform an update . Section 7.7 currently says that " each MLS Commit message needs to transmit a KeyPackage leaf and node values along its direct path " , but section 10.2 says that an UpdatePath is optional . I can update 7.7 as well , if 10.2 is correct . 
 I went ahead and changed Section 7.7 to specify that MLS commits may optionally transmit updates for consistency with Section 10.2
Paragraph (version A):
When performing a Commit, the generator of the Commit updates its
leaf KeyPackage 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 Commit 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 node directly above the leaf,
path_secret[1] for its 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):
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 B):
To begin, the generator of the UpdatePath updates its leaf KeyPackage
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 B):
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 node directly above the leaf,
path_secret[1] for its 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 A):
After performing these operations, the generator of the Commit MUST
delete the leaf_secret.
Paragraph (version A):
After generating a Commit as described in the prior section, the
generator of the Commit must broadcast this update to other members
of the group, who apply it to keep their local views of the tree in
sync with the sender's.  When a client commits a change to the tree
(e.g., to add or remove a member), it transmits a handshake message
containing a set of public and encrypted private values for
intermediate nodes in the direct path of a leaf.  The other members
of the group can use these values to update their view of the tree,
aligning their copy of the tree to the sender's.
Paragraph (version B):
After performing these operations, the generator of the UpdatePath
MUST delete the leaf_secret.
Paragraph (version B):
After generating fresh key material and applying it to ratchet
forward their local tree state as described in the prior section, the
generator must broadcast this update to other members of the group in
a Commit message, who apply it to keep their local views of the tree
in sync with the sender's.  More specifically, when a member commits
a change to the tree (e.g., to add or remove a member), it transmits
a UpdatePath message containing a set of public and encrypted private
values for intermediate nodes in the direct path of a leaf.  The
other members of the group use these values to update their view of
the tree, aligning their copy of the tree to the sender's.
Paragraph (version A):
As described in commit, each MLS Commit message needs to transmit a
KeyPackage leaf and node values along its direct path.  The path
contains a public key and encrypted secret value for all intermediate
nodes in the path above the leaf.  The path is ordered from the
closest node to the leaf to the root; each node MUST be the parent of
its predecessor.
Paragraph (version B):
As described in commit, each MLS Commit message may optionally
transmit a KeyPackage leaf and node values along its direct path.
The path contains a public key and encrypted secret value for all
intermediate nodes in the path above the leaf.  The path is ordered
from the closest node to the leaf to the root; each node MUST be the
parent of its predecessor.