Draft: draft-ietf-mls-protocol

Commentary: I do n't like the pattern of having a marker byte followed by zero - padding . It has to be parsed manually , backwards , unlike every other object in the protocol which all follow a common format . 
 Agreement at the interim was that people do n't care about the overhead ( for now ) , so we 're going to go with the simpler , TLS - syntax - based structure . 
 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 .
Paragraph (version A):
A ClientInitKey object specifies a ciphersuite that the client
supports, as well as providing a public key that others can use for
key agreement.  The client's identity key is intended to be stable
throughout the lifetime of the group; there is no mechanism to change
it.  Init keys are intended to be used a very limited number of
times, ideally only once.  (See init-key-reuse).  Clients MAY
generate and publish multiple ClientInitKey objects to support
multiple ciphersuites, or to reduce the likelihood of init key reuse.
ClientInitKeys contain an identifier chosen by the client, which the
client MUST assure uniquely identifies a given ClientInitKey object
among the set of ClientInitKeys created by this client.
Paragraph (version B):
A ClientInitKey object specifies a ciphersuite that the client
supports, as well as providing a public key that others can use for
key agreement.  The client's identity key is intended to be stable
throughout the lifetime of the group; there is no mechanism to change
it.  Init keys are intended to be used a very limited number of
times, ideally only once.  (See init-key-reuse).  Clients MAY
generate and publish multiple ClientInitKey objects to support
multiple ciphersuites, or to reduce the likelihood of init key reuse.
ClientInitKeys contain an identifier chosen by the client, which the
client MUST ensure uniquely identifies a given ClientInitKey object
among the set of ClientInitKeys created by this client.
Paragraph (version A):
Handshake and application messages use a common framing structure.
This framing provides encryption to assure confidentiality within the
group, as well as signing to authenticate the sender within the
group.
Paragraph (version B):
Handshake and application messages use a common framing structure.
This framing provides encryption to ensure confidentiality within the
group, as well as signing to authenticate the sender within the
group.