Draft: draft-ietf-mls-protocol

Commentary: This PR revises the parent hash verification section to reflect more recent discussion . Right now , the definition of validity according to the parent hash ties it to the " top - down " validation algorithm , when what really matters is that each parent node has a path to a leaf . This PR changes the definition to that more general version , and mentions the " top - down " and " bottom - up " approaches to checking this property . 
 cc 
 Great proposal ! It achieves what we want much more directly . One comment : in the description of the " top down " approach , the part " there is exactly one descendant " is n't exactly consistent with being " parent hash valid " , because the latter requires that P can be chained to at least one leaf . The bottom up approach is consistent with being parent hash valid . As a result , a malicious insider may be able to craft a tree that is accepted by the bottom up approach but not by the top down approach [ 1 ] which may hurt interoperability . I 'd suggest either to change " exactly one " to " at least one " in the top down approach or to change " can be chained back to a leaf " to " can be chained back to exactly one leaf " in the definition of parent hash valid ( and modify the bottom up approach accordingly ) . I do n't have a strong opinion which is better . [ 1 ] An example such tree : the tree has 3 nodes : the root P and its children A and B. Assuming both A and B are malicious , A signs the parent hash of P with copath child B and B signs the parent hash of P with copath child A. ( This is possible with the current resolution - hash for parent - hash . ) 
 - I am keen on the " exactly one " framing precisely because you should n't have these collisions in a real tree . At least I have n't been able to think up a case ; maybe you have a non - malicious case ? Given that , I 'm inclined to tighten the " bottom - up " so that it fails if there are multiple valid paths to a node . 
 Just to close the loop here : - thanks for the suggestion , a sentence - Updated the " bottom up " description to say that each node should be covered by exactly one chain , which is the parallel requirement to exactly one child . 
 Note that this does n't completely address the " unease " feeling mentioned in , but I can live it . Other than that , I think it makes the parent hash construct a lot more clear and this PR has a lot of pedagogical value . The section on parent hash in the current document is really difficult to grasp for a newcomer .
Paragraph (version A):
To this end, when processing a Commit message clients MUST recompute
the expected value of "parent_hash" for the committer's new leaf and
verify that it matches the "parent_hash" value in the supplied
"leaf_node".  Moreover, when joining a group, new members MUST
authenticate each non-blank parent node P.  A parent node P is
authenticated by checking that there exists a child V of P and a node
U in the resolution of V such that V."parent_hash" is equal to the
Parent Hash of P with V's sibling as the co-path child.
Paragraph (version B):
Parent hashes are verified at two points in the protocol: When
joining a group and when processing a Commit.
Paragraph (version B):
The "parent_hash" field of U is equal to the parent hash of P with
copath child S, where S is the child of P that is not on the path
from U to P.
Paragraph (version B):
A parent node P is "parent-hash valid" if it can be chained back to a
leaf node in this way.  That is, if there is leaf node L and a
sequence of parent nodes P_1, ..., P_N such that P_N = P and each
step in the chain is authenticated by a parent hash: L's parent hash
is valid with respect to P_1, P_1's parent hash is valid with respect
to P_2, and so on.
Paragraph (version B):
When joining a group, the new member MUST authenticate that each non-
blank parent node P is parent-hash valid.  This can be done "bottom
up" by building chains up from leaves and verifying that all non-
blank parent nodes are covered by exactly one such chain, or "top
down" by verifying that there is exactly one descendant of each non-
blank parent node for which the parent node is parent-hash valid.
Paragraph (version B):
When processing a Commit message that includes an UpdatePath, clients
MUST recompute the expected value of "parent_hash" for the
committer's new leaf and verify that it matches the "parent_hash"
value in the supplied "leaf_node".  After being merged into the tree,
the nodes in the UpdatePath form a parent-hash chain from the
committer's leaf to the root.