Draft: draft-barnes-mls-protocol

Commentary: Also add myself as an author , and compensate for emacs 's proclivities . 
 The goal of the reinit proposal is to trigger a tear down / restart of a group with the same members but different parameters such as a version upgrade , or a cipher suite change . version - version is a field within key package , and this locks a key package to a specific version , even if capabilities allow for multiple versions . Should that field be removed , and instead you just look at capabilities ? It seems that this would change with since leaf nodes will not be pinned to a specific version , just a cipher suite . After 575 gets merged one could upgrade versions using a new tree that copies the current non - empty leaves so long as each leaf has the upgraded version in their capabilities set . That specific tree building process is not mentioned , it is just sort of assumed in context .     the case you want to change   , complexity somewhat increases . You will need to create a new tree by grabbing new key packages for each participant , and because the cipher suite has changed , all of the credentials have also changed . It is mentioned that " A group may be reinitialized by creating a new group with the same membership and different parameters " , but this does not have a statement that has a SHOULD or MUST associated with it . For example , in my 5000 member group 1 member does not support the cipher suite that we are migrating away from . As the committer , I 'm assuming that I should keep everyone in the group as best effort , but have the option to filter out problematic members that are blocking a migration due to them being offline for long periods of time or having outdated software . Due to the credential change , enforcing a MUST might be difficult since equality between two x509 credentials is not straight forward for example . To summarize , I propose some changes version from key package , and rely on capabilities instead , this may now be irrelevant due to , but the version and capabilities.versions values seem duplicative some language in reinitialization that clarifies the flow for upgrading just version vs changing cipher suite , where changing cipher suite explicitly requires you acquire new key packages for each member . that a person issuing the welcome based on a reinit proposal SHOULD include all existing members 
 those fields have quite separate purposes . Keep in mind that a different version could have a different KeyPackage format . So says " this KeyPackage is formatted according to this version " , while the capabilities says what other versions I support . that in mind , you need to grab new KeyPackages for everyone regardless of whether you 're changing version , ciphersuite , or both . If this is n't clear , we should certainly clarify it . you 're worried about people not supporting the new stuff , you could maintain the hard semantic just by Removing those participants that do n't support the new stuff before you ReInit . 
 Fair enough that seems reasonableI do n't think it 's necessarily clear right now , it 's more of an assumption based on an understanding of the protocol overall . I 'll try to come up with something there to give more of a step by step explanation of the flow . If this is a hard requirement should the doc say MUST here ? If so , I 'm trying to think through what equality means in terms of membership when in the event the cipher suite changes , all the credentials will also change . 
 On ( 3 ) -- I would be OK with saying that the new members MUST be the same as the old members . The notion of " same " is a little squishy , given ambiguities around identifiers , but it seems like it will probably be clear in practice . W.r.t . removing people to make an upgrade possible , when the application decides to upgrade and how the application it meets the same - member criterion is up to the application . 
 Discussion on virtual interim : Maybe put " remove before upgrade " in implementation considerations document . 
 I meant to make this call to discuss , seem to not have the invite anymore , can you forward it to me ? In terms of where this ticket is at , I was mostly raising the concerns to clarify for myself that what I think is the process is actually the process . I am willing to just close this one out
Paragraph (version A):
Messaging applications are increasingly making use of end-to-end
security mechanisms to ensure that messages are only accessible to
the communicating endpoints, not any servers involved in delivering
messages.  Establishing keys to provide such protections is
challenging for group chat settings, in which more than two
participants need to agree on a key.  In this document, we specify a
group key establishment protocol that provides efficient group key
establishment with forward secrecy and post-compromise security.
Paragraph (version B):
Messaging applications are increasingly making use of end-to-end
security mechanisms to ensure that messages are only accessible to
the communicating endpoints, not any servers involved in delivering
messages.  Establishing keys to provide such protections is
challenging for group chat settings, in which more than two
participants need to agree on a key but may not be online at the same
time.  In this document, we specify a group key establishment
protocol that provides efficient asynchronous group key establishment
with forward secrecy and post-compromise security.
Paragraph (version B):
Groups of agents who want to send each other encrypted messages need
a way to derive shared symmetric encryption keys.  For two parties
this problem has been studied thoroughly, with the Double Ratchet
emerging as a common solution; channels implementing the Double
Ratchet enjoy fine-grained forward secrecy as well as post-compromise
security, but are nonetheless efficient enough for heavy use over
low-bandwidth networks.
Paragraph (version B):
For groups of size greater than two, the state of the art is to
unilaterally broadcast symmetric "sender" keys over existing shared
symmetric channels, and then for each agent to send messages to the
group encrypted with their own sender key.  Unfortunately, while this
is efficient and (with the addition of a hash ratchet) provides
forward secrecy, it does not have post-compromise security.  An
adversary who learns a sender key can therefore indefinitely and
passively eavesdrop on that sender's messages.
Paragraph (version B):
Rekeying, or generating new sender keys, provides a form of post-
compromise security.  However, it requires a separate message to each
potential receiver.  In this document we describe a tree-based system
for deriving group keys which provides post-compromise security with
efficient rekeys and without requiring any two parties to be online
concurrently.