Draft: draft-ietf-mls-protocol

Commentary: a new member instantiates the group state , they can verify the confirmation MAC that was sent in the Commit that created the state . This lets new members verify that they 've joined correctly . ( It does not assure that they 're seeing the same confirmation as anyone else . ) of generating a fresh key , we can simply provide the epoch key in the key package and derive the GroupInfo encryption key from it . This avoids relying on fresh entropy , and makes it more difficult for the sender to provide different keys that will all decrypt and authenticate the GroupInfo . 
 This appears to have been rendered obsolete by 
 Actually this is the nice one providing the nice properties , unlike which breaks the cryptographic properties we expect from the secrecy invariant ( see ) 
 Ah , thank you for reminding me of ! I will rebase this and merge . 
 In the there is a sub - bullet for creating the GroupInfo object / Welcome message that says : Then , in it is stated that : However , from what I can tell , it is not explained anywhere how the key and nonce should be derived from the . If it is somewhere , can someone point it out to me ? If it is not in the RFC , should it be included ? 
 Thanks ! There is indeed missing definitions in the document . On a side note , I labelled this a security issue as I suspect there is a design issue to handle . The secrets derived from the init_secret are cryptographically associated to the previous group , not the current one , which breaks the secrecy invariant . I would much prefer to derive and encrypt under keys that are cryptographically associated to the new group and reveal those to the newcomer . 
 Relates to 
 I will make sure this gets covered in the revived 
 Fixed in 
 Sending the and the at once seem equivalent to sending the but I do n't think it is actually the case since the message could be rejected by the DS , breaking the encryption key of that message would hence still have consequences even if the message is rejected . Technically this is also breaking secrecy of the because the principals of the protocol which are associated to its secrecy are the members of the previous epoch , while the principals associated to the do contain the newcomer . I think we should update this mechanism to send the directly .  ... 
 Fixed in 
 Here 's the Weekly Digest for : - - Last week 4 issues were created . Of these , 0 issues have been closed and 4 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by - - Last week , 14 pull requests were created , updated or merged . Last week , 8 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 6 pull requests were merged . : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by : purpleheart : , by - - Last week there were 10 commits . : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by : hammerandwrench : by - - Last week there were 3 contributors . : bustinsilhouette : : 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 11 issues were created . Of these , 1 issues have been closed and 10 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : heart : , by : speaker : , by It received 2 comments . - - Last week , 11 pull requests were created , updated or merged . Last week , 6 pull requests were opened . : greenheart : , by : greenheart : , by : greenheart : , by : greenheart : , by : 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 2 commits . : hammerandwrench : by : hammerandwrench : by - - Last week there were 2 contributors . : bustinsilhouette : : bustin_silhouette : - - 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 . 
 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 . *
Paragraph (version B):
We describe the information stored by each client as _state_, which
includes both public and private data.  An initial state is set up by
a group creator, which is a group containing only themself.  The
creator then sends _Add_ proposals for each client in the initial set
of members, followed by a _Commit_ message which incorporates all of
the _Adds_ into the group state.  Finally, the group creator
generates a _Welcome_ message corresponding to the Commit and sends
this directly to all the new members, who can use the information it
contains to set up their own group state and derive a shared secret.
Members exchange Commit messages for post-compromise security, to add
new members, and to remove existing members.  These messages produce
new shared secrets which are causally linked to their predecessors,
forming a logical Directed Acyclic Graph (DAG) of states.
Paragraph (version A):
It is left to the application to determine the interval of time
between Update messages.  This policy could require a change for each
message, or it could require sending an update every week or more.
Paragraph (version A):
A binary tree is _left-balanced_ if for every parent, either the
parent is balanced, or the left subtree of that parent is the largest
full subtree that could be constructed from the leaves present in the
parent's own subtree.  Note that given a list of "n" items, there is
a unique left-balanced binary tree structure with these elements as
leaves.  In such a left-balanced tree, the "k-th" leaf node refers to
the "k-th" leaf node in the tree when counting from the left,
starting from 0.
Paragraph (version B):
No participant in an MLS group knows the private key associated with
every node in the tree.  Instead, each member is assigned to a leaf
of the tree, which determines the subset of private keys it knows.
The credential stored at that leaf is one provided by the member.
Paragraph (version B):
In other words, if a node is not blank, then it holds a public key.
The corresponding private key is known only to members occupying
leaves below that node.
Paragraph (version B):
The reverse implication is not true: A member may not know the
private keys of all the intermediate nodes they're below.  Such a
member has an _unmerged_ leaf.  Encrypting to an intermediate node
requires encrypting to the node's public key, as well as the public
keys of all the unmerged leaves below it.  A leaf is unmerged when it
is first added, because the process of adding the leaf does not give
it access to all of the nodes above it in the tree.  Leaves are
"merged" as they receive the private keys for nodes, as described in
ratchet-tree-evolution.
Paragraph (version B):
The hash of a tree is the hash of its root node, which we define
recursively, starting with the leaves.
Paragraph (version B):
The "confirmed_transcript_hash" field contains a running hash over
the messages that led to this state.
Paragraph (version B):
The exported values are bound to the Group epoch from which the
"exporter_secret" is derived, hence reflects a particular state of
the Group.
Paragraph (version B):
It is RECOMMENDED for the application generating exported values to
refresh those values after a group operation is processed.
Paragraph (version A):
Decryption follows the same step in reverse: Decrypt the metadata,
then the message and verify the content signature.
Paragraph (version A):
The key and nonce used for the encryption of the message depend on
the content type of the message.  The sender chooses the handshake
key for a handshake message or an ununsed generation from its (per-
sender) application key chain for the current epoch, according to the
type of message being encrypted.
Paragraph (version B):
The key and nonce used for the encryption of the message depend on
the content type of the message.  The sender chooses the handshake
key for a handshake message or an unused generation from its (per-
sender) application key chain for the current epoch, according to the
type of message being encrypted.
Paragraph (version B):
Use the "commit_secret", the provisional GroupContext, and the
init secret from the previous epoch to compute the epoch secret
and derived secrets for the new epoch.
Paragraph (version B):
Use the "epoch_secret" from the KeyPackage object to generate the
epoch secret and other derived secrets for the current epoch.
Paragraph (version B):
Set the confirmed transcript hash in the new state to the value of
the "confirmed_transcript_hash" in the GroupInfo.
Paragraph (version A):
Each handshake message is premised on a given starting state,
indicated in its "prior_epoch" field.  If the changes implied by a
handshake messages are made starting from a different state, the
results will be incorrect.
Paragraph (version A):
This need for sequencing is not a problem as long as each time a
group member sends a handshake message, it is based on the most
current state of the group.  In practice, however, there is a risk
that two members will generate handshake messages simultaneously,
based on the same state.
Paragraph (version A):
Regardless of how messages are kept in sequence, implementations MUST
only update their cryptographic state when valid handshake messages
are received.  Generation of handshake messages MUST be stateless,
since the endpoint cannot know at that time whether the change
implied by the handshake message will succeed or not.
Paragraph (version B):
As long as Commit messages cannot be merged, there is a risk of
starvation.  In a sufficiently busy group, a given member may never
be able to send a Commit message, because he always loses to other
members.  The degree to which this is a practical problem will depend
on the dynamics of the application.
Paragraph (version B):
It might be possible, because of the non-contributivity of
intermediate nodes, that Commit messages could be applied one after
the other without the Delivery Service having to reject any Commit
message, which would make MLS more resilient regarding the
concurrency of Commit messages.  The Messaging system can decide to
choose the order for applying the state changes.  Note that there are
certain cases (if no total ordering is applied by the Delivery
Service) where the ordering is important for security, ie. all
updates must be executed before removes.
Paragraph (version B):
Here, S may be the "init_secret", "commit_secret", "epoch_secret",
"application_secret" as well as any secret in the AS Tree or one of
the ratchets.
Paragraph (version B):
As soon as a group member consumes a value they MUST immediately
delete (all representations of) that value.  This is crucial to
ensuring forward secrecy for past messages.  Members MAY keep
unconsumed values around for some reasonable amount of time to handle
out-of-order message delivery.
Paragraph (version B):
the "init_secret", "commit_secret", "epoch_secret",
"application_secret" of that epoch,
Paragraph (version B):
Then if a client uses key KD1 and nonce ND1 during epoch n then it
must consume (at least) values G, F, D0, D1, KD1, ND1 as well as the
"commit_secret" and init_secret used to derive G (the
application_secret).  The client MAY retain (not consume) the values
KD0 and ND0 to allow for out-of-order delivery, and SHOULD retain D2
to allow for processing future messages.
Paragraph (version A):
Message encryption keys are derived via a hash ratchet, which
provides a form of forward secrecy: learning a message key does not
reveal previous message or root keys.  Post-compromise security is
provided by Update operations, in which a new root key is generated
from the latest ratcheting tree.  If the adversary cannot derive the
updated root key after an Update operation, it cannot compute any
derived secrets.