Draft: draft-ietf-mls-protocol

Commentary: After the discussion at the interim I took a look again and I would like to bring up the following points : The PR contains functional changes as well as editorial changes . I think it makes no sense to combine the two and the two kind of changes should be split in at least two PRs . We discussed that enforcing the tree invariant is the minimum we need , there is still an ongoing discussion on what we want to guarantee regarding group agreement . This PR covers more than just the direct path needed for the tree invariant , because the fields and are present in . Is this on done on purpose ? If so , why ? I think it is not actually possible to verify the hash chain in a direct path other than in the direct path of the last Commit . The reason is that the hash chain breaks on all other direct paths because at some level the direct path gets overwritten by the direct path of the committer and the hashes are therefore no longer correct . The way forward would be to use a  tree instead of a hash in the CIK extension ( I think proposed that at some point ) . 
 You can now rebase this on master for clarity . Please avoid unrelated editorial as much as possible . 
 As discussed on PR call : People are generally OK going with this approach for now , pending further proofs We should get and merged first 
 I think the last commits address my concerns . 
 One more note here : It might be good to add an OPEN ISSUE to acknowledge the still - outstanding concerns about group agreement vs. deniability , , something like : 
 Here 's the Weekly Digest for : - - Last week 5 issues were created . Of these , 1 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by : speaker : , by It received 3 comments . - - Last week , 8 pull requests were created , updated or merged . Last week , 7 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 1 pull request was merged . : purpleheart : , by - - Last week there were 3 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustinsilhouette : - - Last week there were no stargazers . - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also .
Paragraph (version B):
A hash of the node's parent, as of the last time the node was
changed.
Paragraph (version A):
Replace the public keys for nodes on the direct path with the
received public keys.
Paragraph (version B):
For all updated nodes,
Paragraph (version B):
Replace the public key for each node with the received
public key.
Paragraph (version B):
Set the list of unmerged leaves to the empty list.
Paragraph (version B):
Store the updated hash of the node's parent (represented as
a ParentNode struct), going from root to leaf, so that each
hash incorporates all the nodes above it.  The root node
always has a zero-length hash for this value.
Paragraph (version B):
This extension MUST be present in all Updates that are sent as part
of a Commit message.  If the extension is present, clients MUST
verify that "parent_hash" matches the hash of the leaf's parent node
when represented as a ParentNode struct.
Paragraph (version B):
A group member that has observed one or more proposals within an
epoch MUST send a Commit message before sending application data.
This ensures, for example, that any members whose removal was
proposed during the epoch are actually removed before any application
data is transmitted.
Paragraph (version B):
The sender of a Commit MUST include all valid proposals that it has
received during the current epoch.  Invalid proposals include, for
example, proposals with an invalid signature or proposals that are
semantically invalid, such as an Add when the sender does not have
the application-level permission to add new users.  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 prefer any Remove received, or the most
recent Update for the leaf if there are no Removes.  If there are
multiple Add proposals for the same client, the committer again
chooses one to include and considers the rest invalid.
Paragraph (version B):
Apply the DirectPath to the tree, as described in
synchronizing-views-of-the-tree.  Define "commit_secret" as the
value "path_secret[n+1]" derived from the "path_secret[n]"
value assigned to the root node.
Paragraph (version B):
Verify the integrity of the ratchet tree.
Paragraph (version B):
Apply the DirectPath to the tree, as described in
synchronizing-views-of-the-tree.
Paragraph (version A):
With this approach, the delivery service ensures that incoming
messages are added to an ordered queue and outgoing messages are
dispatched in the same order.  The server is trusted to resolve
conflicts during race-conditions (when two members send a message at
the same time), as the server doesn't have any additional knowledge
thanks to the confidentiality of the messages.
Paragraph (version B):
Regardless of how messages are kept in sequence, implementations MUST
only update their cryptographic state when valid Commit messages are
received.  Generation of Commit messages MUST NOT modify a client's
state, since the endpoint doesn't know at that time whether the
changes implied by the Commit message will succeed or not.
Paragraph (version B):
With this approach, the delivery service ensures that incoming
messages are added to an ordered queue and outgoing messages are
dispatched in the same order.  The server is trusted to break ties
when two members send a Commit message at the same time.