Draft: draft-ietf-mls-protocol

Commentary: This PR implements the proposal discussed in Prague and on the mailing list , to separate GroupOperations into Proposals and Commits . This change leaves the underlying ratchet tree operations untouched , but changes how these operations are folded into the overall key schedule . This is also a fairly initial effort , with several OPEN ISSUEs noted . The most important IMO is that we should allow a single MLSPlaintext to pack one or more Proposals along with a Commit , which makes it simpler to emulate the current behavior , and might allow us to get rid of the Init message . 
 Note : Need to stop truncating hash of proposal 
 This is good . Thanks  ! 
 Here 's the Weekly Digest for : - - Last week , no issues were created . - - Last week , 5 pull requests were created , updated or merged . Last week , 3 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 2 pull requests were merged . : purpleheart : , by : purpleheart : , by - - Last week there were 2 commits . : hammerandwrench : by : hammerandwrench : by - - Last week there was 1 contributor . : bustin_silhouette : - - 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 . 
 Here 's the Weekly Digest for : - - Last week 18 issues were created . Of these , 3 issues have been closed and 15 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by : heart : , by : heart : , by : speaker : , by It received 5 comments . - - Last week , 10 pull requests were created , updated or merged . Last week , 1 pull request was opened . : greenheart : , by Last week , 7 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 2 pull requests were merged . : purpleheart : , by : purpleheart : , by - - Last week there were 4 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 4 contributors . : bustinsilhouette : : bustinsilhouette : : bustinsilhouette : : bustin_silhouette : - - 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 . 
 At a minimum we need to make handshake key chains . If we do Proposals ( ) , then we will need to encrypt multiple handshake message per epoch , so we will need key chains instead of just a single handshake key . Even if we do n't do , this would improve symmetry / code reuse . Specifically , we should repurpose the ASTree " per - user secret tree " . Instead of the leaves of the tree being the starting point for an application key chain , there would be used to derive the starting points for the application key chain , handshake key chain , and possibly exported per - user secrets . 
 This ended up not being necessary . For handshake messages , we do n't need forward secrecy within an epoch , so the full AStree machinery is n't necessary . Instead we use the simple TLS - like nonce updating described in 
 Instead of initializing new members with information from the previous epoch and requiring them to process an Add , we should initialize new members directly with current epoch information . This is covered in , but should be factored out . 
 Dependent on : Some modeling to convince ourselves that removing is n't dangerous Blocks : 
 I have made a Tamarin model of the 2- and 3 - member cases of the proposal in , which shows that it provides certain authentication properties that one should expect of an AKE . In particular , it provides the property that even if the adder is malicious , they can not cause the new member and the existing members to come to differing views of the group without causing to group to decohere . ( Since the GroupContext is included in the key schedule , this might not be surprising . ) Tamarin model here : Given this analysis , I 'm comfortable making this change . It 's preliminary , but I think it 's good enough to justify moving forward with this concept pending a more complete analysis . 
 Fixed in 
 Here 's the Weekly Digest for : - - Last week , no issues were created . - - Last week , 1 pull request was created , updated or merged . Last week , 1 pull request was updated . : yellow_heart : , by - - Last week there were no commits . - - Last week there were no contributors . - - 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 . 
 Here 's the Weekly Digest for : - - Last week 3 issues were created . Of these , 1 issues have been closed and 2 issues are still open . : greenheart : , by : greenheart : , by : heart : , by : speaker : , by It received 1 comments . - - Last week , 6 pull requests were created , updated or merged . Last week , 1 pull request was opened . : greenheart : , by Last week , 1 pull request was updated . : yellowheart : , by Last week , 4 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 6 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there was 1 contributor . : bustinsilhouette : - - Last week there was 1 stargazer . : star : You are the star ! : star2 : - - 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 . 
 A few changes needed , but I would be fine with fixing in subsequent PRs .
Paragraph (version B):
A client creates a group with a specified set of initial members by
constructing an Init message and sending it to those members.
Paragraph (version B):
Note the group ID, protocol version, and ciphersuite in use.
Paragraph (version B):
The members learn the relevant path secrets by decrypting one of the
encrypted path secrets in the DirectPath and working back to the root
(as in normal DirectPath processing).
Paragraph (version B):
Note the degenerate case of this process: The group creator can
initialize a group with one member (itself) and add the remaining
members by sending Add proposals followed by a Commit.  This approach
is slightly more verbose than simply sending an Init message, but
also slightly more private.  The Init leaks the initial configuration
of the group, while in the Add approach, the initial group state is
sent in encrypted Welcome messages.
Paragraph (version B):
A Remove proposal requests that the client at a specified index in
the tree be removed from the group.
Paragraph (version B):
A Commit message initiates a new epoch for the group, based on a
collection of Proposals.  It instructs group members to update their
representation of the state of the group by applying the proposals
and advancing the key schedule.
Paragraph (version B):
Update the ratchet tree by replacing nodes in the direct path
of the sender with the corresponding nodes in the path (see
direct-paths).
Paragraph (version B):
The sender of a Commit message is responsible for sending Welcome
messages to any new members added via Add proposals.  The Welcome
message provides the new member with the current state of the group,
after the application of the Commit message.  So the new member will
not be able to decrypt or verify the Commit message, but will have
the secrets it needs to participate in the epoch initiated by the
Commit message.
Paragraph (version B):
The information in a Welcome message is encrypted for the new member
using HPKE.  The recipient key pair for the HPKE encryption is the
one included in the indicated ClientInitKey.