Draft: draft-ietf-mls-protocol

Commentary: The current draft uses a hash ratchet to derive single - use keys for application messages , but for handshake messages , re - uses the same key with a sequence of different nonces . This results in a lot of unnecessary extra code . This PR uses the same hash ratchet for handshake and application messages . The only difference is in the base key for the hash ratchet . In the application case , we use the AStree . In the HS case , we derive the base keys directly from the handshake secret . The lack of a tree in the HS case means that either the client will do a linear number of derivations on the first send / receive , or it will keep the handshake secret around and not get FS for handshake messages within the epoch . 
 - would appreciate your thoughts here 
 As discussed on the PR call : There 's no point to FS for Proposals because clients have to cache the plaintext anyway Given that , the " flat derivation " approach should be fine We should have separate keys per sender to it easier to avoid nonce collisions  whether we should derive nonces on a hash ratchet or use a counter 
 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 . 
 Here 's the Weekly Digest for : - - Last week 3 issues were created . Of these , 0 issues have been closed and 3 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : speaker : , by It received 1 comments . - - Last week , 7 pull requests were created , updated or merged . Last week , 2 pull requests were opened . : greenheart : , by : greenheart : , by Last week , 4 pull requests were updated . : 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 2 stagazers . : star : : star : You all are the stars ! : 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 . 
 Please merge when you have chance .
Paragraph (version A):
Here the value [sender] represents the index of the member that will
use this key to send, encoded as a uint32.  Each sender maintains two
"generation" counters, one for application messages and one for
handshake messages.  These counters are incremented by one each time
the sender sends a message.
Paragraph (version A):
For application messages, a chain of keys is derived for each sender
in a similar fashion.  This allows forward secrecy at the level of
application messages within and out of an epoch.  A step in this
chain (the second subscript) is called a "generation".  The details
of application key derivation are described in the astree section
below.
Paragraph (version A):
where "encode_big_endian()" encodes the generation in a big-endian
integer of the same size as the base handshake nonce.
Paragraph (version B):
For handshake and application messages, a sequence of keys is derived
via a "sender ratchet".  Each sender has their own sender ratchet,
and each step along the ratchet is called a "generation".
Paragraph (version B):
A sender ratchet starts from a per-sender base secret.  For
application keys, the base secret is derived as described in astree.
For handshake keys, base secrets are derived directly from the
"handshake_secret".
Paragraph (version B):
The base secret of for each sender is used to initiate a symmetric
hash ratchet which generates a sequence of keys and nonces.  The
sender uses the j-th key/nonce pair in the sequence to encrypt (using
the AEAD) the j-th message they send during that epoch.  In
particular, each key/nonce pair MUST NOT be used to encrypt more than
one message.
Paragraph (version B):
Here, AEAD.nonce_length and AEAD.key_length denote the lengths in
bytes of the nonce and key for the AEAD scheme defined by the
ciphersuite.  "ratchet" should be understood to mean "handshake" or
"application" depending on the context.
Paragraph (version A):
The secret of a leaf in the AS Tree is used to initiate a symmetric
hash ratchet which generates a sequence of keys and nonces.  The
group member assigned to that leaf uses the j-th key/nonce pair in
the sequence to encrypt (using the AEAD) the j-th message they send
during that epoch.  In particular, each key/nonce pair MUST NOT be
used to encrypt more than one message.
Paragraph (version A):
More precisely, the initial secret of the ratchet for the group
member assigned to the leaf with node index N is simply the secret of
that leaf.
Paragraph (version A):
Here, AEAD.nonce_length and AEAD.key_length denote the lengths in
bytes of the nonce and key for the AEAD scheme defined by the
ciphersuite.
Paragraph (version B):
The secret in the leaf of the AS tree is used to initiate a symmetric
hash ratchet, from which a sequence of single-use keys and nonces are
derived, as described in encryption-keys.