Draft: draft-ietf-mls-protocol

Commentary: As discussed on the list , this PR replaces the explicit tree and roster inputs to the key schedule with a " tree hash " construct . - Given this , do you think we need to keep the field around ? It seems like in TLS and similar , the transcript hash is there to ensure that the parties agree on things like identities , but we 're encoding all that explicitly . 
 This is roughly what we do for the TreeKEM paper ( I believe we do n't re - mix the identities at each op . if I am correct ) . This seem to cover enough so it 's good . I 'll try to have a deeper look tomorrow , but this looks reasonable at first glance . It covers both the identities / roster and the group operations , ( quid of the welcome message ? ) so yes this makes the transcript hash redundant it seems :) I 'll get back asap . Edit : as discussed before let 's keep the transcript hash for now . 
 If the goal is to have a new data structure that combined and replaces the ratchet tree and roster , then parent and leaf nodes should be storing a lot more information . Namely , if this to be used as a ratchet tree , all nodes need to have associated public keys and private keys , and parent nodes should retain a hash of their children . No need to store node secrets , though . They 're never used after private key derivation . 
 I think the definition of Resolution should be in the Tree Computation Terminology section , not the Ratchet Tree Contents section 
 Currently , the whole GroupState object is folded into the key schedule , via the function . Could this be simplified ? For example : Hash the GroupState object once , and use it for all calls , as opposed to passing it by value each time Hash in the roster and tree as a commitment ( cf ) rather than by value Other suggestions welcome . 
 I think we can get away with using the transcript hash if we put a little more information in the transcript . In particular , the Welcome message needs to be included to assure that the new joiner and the group have the same view of the group state bits in the Welcome message .
Paragraph (version B):
We generally assume that each participant maintains a complete and
up-to-date view of the public state of the group's ratchet tree,
including the public keys for all nodes and the credentials
associated with the leaf nodes.
Paragraph (version B):
The members of the group need to keep their views of the tree in sync
and up to date.  When a client proposes a change to the tree (e.g.,
to add or remove a member), it transmits a set of public values for
intermediate nodes in the direct path of a leaf.  The other members
of the group can use these public values to update their view of the
tree, aligning their copy of the tree to the sender's.
Paragraph (version B):
Look up the credential for the leaf node at position
"signer_index" in the current ratchet tree (before the update).
Paragraph (version B):
Use that public key to verify the "signature" field in the
Handshake message, as described below.
Paragraph (version B):
Use the "confirmation_key" for the provisional group state to
compute the "confirmation" MAC for this message, as described
below, and verify that it is the same as the "confirmation" field.
Paragraph (version B):
If either the signature or the MAC fails to verify, discard the
provisional GroupState object and consider the Handshake message
invalid.
Paragraph (version B):
If the the above checks are successful, accept the provisional
GroupState object as the current state of the group.
Paragraph (version B):
Note that [sender] represents the represents the leaf index of the
ratchet tree leaf assigned to the sender.