Draft: draft-ietf-mls-protocol

Commentary: This has been reported unclear multiple times . I strongly prefer forbidding reuse altogether . A validation mechanism is needed for the formal security proof , it can be implemented according to an expiration mechanism ( see Architecture - 4.2 . Delivery Service Compromise ) 
 We need to allow Last Resort keys . Not sure what you mean by " replay attacks " 
 I rewrote it in favor of using " SHOULD NOT reuse " , which is true , except in case of last resort to avoid DOS , which we are willing to allow . Normal meaning ... If I remember correctly , there is a cross channel forwarding attack ( replay ) possible on the first message in Signal when reusing prekeys ( the last resort key ) because it lacks some channel binding but I would have to check . I am working to make sure we do n't suffer the same defect but I am documenting it in the mean time . 
 I can live with this for now ; we can refine later . 
 Here 's the Weekly Digest for : - - Last week 9 issues were created . Of these , 6 issues have been closed and 3 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by : heart : , by : heart : , by : heart : , by : heart : , by : heart : , by : speaker : , by It received 2 comments . - - Last week , 13 pull requests were created , updated or merged . Last week , 3 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 10 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 38 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustin_silhouette : - - 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 . * 
 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 .
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 ensure 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 only once and SHOULD NOT be
reused except in case of last resort.  (See init-key-reuse).  Clients
MAY generate and publish multiple ClientInitKey objects to support
multiple ciphersuites.  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):
Initialization keys are intended to be used only once and then
deleted.  Reuse of init keys is not believed to be inherently
insecure dhreuse, although it can complicate protocol analyses.
Paragraph (version B):
Initialization keys are intended to be used only once and then
deleted.  Reuse of init keys can lead to replay attacks.