Draft: draft-ietf-mls-protocol

Commentary: This PR builds on and . It adds the following : An explicit note in that implementations may use any representation A general description of how nodes are to / removed from the tree Specific algorithms for " array - based trees " and " link - based trees " ( I also made a few minor editorial revisions . ) - I think this hits the right balance of specificity and generality . Interested in your thoughts here . 
 This looks good ! If I am understanding everything well , the normative description for extention / truncation is the section " Adding and Removing Leaves " , which is a tree - based description ? 
 Thanks lgtm now
Paragraph (version B):
The unique power of a ratchet tree is that it allows a group to
efficiently remove a member, because it allows a group member to
efficiently encrypt new entropy to a subset of the group.  A ratchet
tree assigns shared keys to subgroups of the overall group, so that,
for example, encrypting to all but one member of the group requires
only log(N) encryptions, instead of the N-1 encryptions that would be
needed to encrypt to each participant individually (where N is the
number of members in the group).
Paragraph (version B):
This remove operation allows MLS to efficiently achieve post-
compromise security.  In an Update proposal or a full Commit message,
an old, possibly compromised representation of a member is
effeciently removed from the group and replaced with a freshly
generated instance.
Paragraph (version B):
To add a new leaf: Add leaf L as the new rightmost leaf of the tree.
Add a blank parent node P whose right child is L.  P is attached to
the tree as the right child of the only appropriate node to make the
updated tree left-balanced (or set it as a new root).  The former
right child of the P's parent becomes P's left child (or the old root
becomes the P's left child if P is the new root).
Paragraph (version B):
To remove the rightmost leaf: Remove the rightmost leaf node L and
its parent node P.  If P was the root of the tree, P's left child is
now the root of the tree.  Otherwise, set the right child of P's
parent to be the P's left child.
Paragraph (version B):
Note: in the rest of the protocol, the rightmost leaf will be removed
only when it is blank.
Paragraph (version B):
Concrete algorithms for these operations on array-based and link-
based trees are provided in array-based-trees and link-based-trees.
The concrete algorithms are non-normative.  An implementation MAY use
any algorithm that produces the correct tree in its internal
representation.
Paragraph (version A):
Finally, "original_child_resolution" is the array of "HPKEPublicKey"
values of the nodes in the resolution of S but with the
"unmerged_leaves" of P omitted.  For example, in the ratchet tree
depicted in resolution-example the "ParentHashInput" of node 5 with
co-path child 4 would contain an empty "original_child_resolution"
since 4's resolution includes only itself but 4 is also an unmerged
leaf of 5.  Meanwhile, the "ParentHashInput" of node 5 with co-path
child 6 has an array with one element in it: the HPKE public key of
6.
Paragraph (version B):
For the generation of encryption keys and nonces, the key schedule
begins with the "encryption_secret" at the root and derives a tree of
secrets with the same structure as the group's ratchet tree.  Each
leaf in the Secret Tree is associated with the same group member as
the corresponding leaf in the ratchet tree.
Paragraph (version B):
Keys, nonces, and the secrets in ratchets are derived using
DeriveTreeSecret.  The context in a given call consists of the
current position in the ratchet.
Paragraph (version B):
all node secrets in the Secret Tree on the path from the root to
the leaf with node L,
Paragraph (version B):
"application_ratchet_nonce_[L]_[j]" and
"application_ratchet_key_[L]_[j]".
Paragraph (version B):
An Add is applied after being included in a Commit message.  The
position of the Add in the list of proposals determines the leaf node
where the new member will be added.  For the first Add in the Commit,
the corresponding new member will be placed in the leftmost empty
leaf in the tree, for the second Add, the next empty leaf to the
right, etc.  If no empty leaf exists, the tree is extended to the
right.
Paragraph (version B):
For each non-blank intermediate node along the path from the leaf
L to the root, add L's leaf index to the "unmerged_leaves" list
for the node.
Paragraph (version A):
Identify a leaf node containing a key package matching "removed".
This lookup MUST be done on the tree before any non-Remove
proposals have been applied (the "old" tree in the terminology of
commit), since proposals such as Update can change the KeyPackage
stored at a leaf.  Let "removed_index" be the node index of this
leaf node.
Paragraph (version B):
If there are multiple proposals that apply to the same leaf, the
committer chooses one and includes only that one in the Commit,
considering the rest invalid.  The committer MUST NOT include any
Update proposals generated by the committer, since they would be
duplicative with the "path" field in the Commit.  The committer MUST
prefer any Remove received, or the most recent Update for the leaf if
there are no Removes.  If there are multiple Add proposals containing
KeyPackages with the same tuple "(credential.identity, endpoint_id)"
the committer again chooses one to include and considers the rest
invalid.  Add proposals that contain KeyPackages with an
"(credential.identity, endpoint_id)" tuple that matches that of an
existing KeyPackage in the group MUST be considered invalid.  The
comitter MUST consider invalid any Add or Update proposal if the
Credential in the contained KeyPackage shares the same signature key
with a Credential in any leaf of the group, or indeed if the
KeyPackage shares the same "hpke_init_key" with another KeyPackage in
the group.
Paragraph (version B):
The new member's position in the tree is at the leaf "my_leaf",
as defined above.
Paragraph (version B):
Update the leaf "my_leaf" with the private key corresponding to
the public key in the node.