Draft: draft-ietf-mls-protocol

Commentary: 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 . 
 Fixed by
Paragraph (version A):
We describe the information stored by each client as a _state_, which
includes both public and private data.  An initial state, including
an initial set of clients, is set up by a group creator using the
_Init_ algorithm and based on information pre-published by clients.
The creator sends the _Init_ message to the clients, who can then set
up their own group state and derive the same shared secret.  Clients
then exchange messages to produce new shared states which are
causally linked to their predecessors, forming a logical Directed
Acyclic Graph (DAG) of states.  Members can send _Update_ messages
for post-compromise secrecy and new clients can be added or existing
members removed from the group.
Paragraph (version B):
We describe the information stored by each client as a _state_, which
includes both public and private data.  An initial state, including
an initial set of clients, is set up by a group creator using the
_Init_ algorithm and based on information pre-published by clients.
The creator sends the _Init_ message to the clients, who can then set
up their own group state and derive the same shared secret.  Clients
then exchange messages to produce new shared states which are
causally linked to their predecessors, forming a logical Directed
Acyclic Graph (DAG) of states.  Members can send _Commit_ messages
for post-compromise secrecy and new clients can be added or existing
members removed from the group.
Paragraph (version A):
To enforce forward secrecy and post-compromise security of messages,
each member periodically updates its leaf secret which represents its
contribution to the group secret.  Any member of the group can send
an Update at any time by generating a fresh leaf secret and sending
an Update message that describes how to update the group secret with
that new information.  Once all members have processed this message,
the group's secrets will be unknown to an attacker that had
compromised the sender's prior leaf secret.
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):
Members are removed from the group in a similar way, as an update is
effectively removing the old leaf from the group.  Any member of the
group can generate a Remove message that adds new entropy to the
group state that is known to all members except the removed member.
After other participants have processed this message, the group's
secrets will be unknown to the removed participant.  Note that this
does not necessarily imply that any member is actually allowed to
evict other members; groups can layer authentication-based access
control policies on top of these basic mechanism.
Paragraph (version B):
To enforce forward secrecy and post-compromise security of messages,
each member periodically updates its leaf secret which represents its
contribution to the group secret.  Any member of the group can send
an Update at any time by generating a fresh leaf secret and sending
an Commit message that describes how to update the group secret with
that new information.  Once all members have processed this message,
the group's secrets will be unknown to an attacker that had
compromised the sender's prior leaf secret.
Paragraph (version B):
It is left to the application to determine the interval of time
between Update+Commit messages.  This policy could require a change
for each message, or it could require sending an update every week or
more.
Paragraph (version B):
Members are removed from the group in a similar way, as a Commit is
effectively removing the old leaf from the group.  Any member of the
group can generate a Remove proposal followed by a Commit message
that adds new entropy to the group state that is known to all members
except the removed member.  After other participants have processed
this message, the group's secrets will be unknown to the removed
participant.  Note that this does not necessarily imply that any
member is actually allowed to evict other members; groups can layer
authentication-based access control policies on top of these basic
mechanism.
Paragraph (version A):
Nodes in a tree are always updated along the direct path from a leaf
to the root.  The generator of the update chooses a random secret
value "path_secret[0]", and generates a sequence of "path secrets",
one for each node from the leaf to the root.  That is, path_secret[0]
is used for the leaf, path_secret[1] for its parent, and so on.  At
each step, the path secret is used to derive a new secret value for
the corresponding node, from which the node's key pair is derived.
Paragraph (version B):
Nodes in a tree are always updated along the direct path from a leaf
to the root.  The generator of the Commit chooses a random secret
value "path_secret[0]", and generates a sequence of "path secrets",
one for each node from the leaf to the root.  That is, path_secret[0]
is used for the leaf, path_secret[1] for its parent, and so on.  At
each step, the path secret is used to derive a new secret value for
the corresponding node, from which the node's key pair is derived.
Paragraph (version A):
As described in ratchet-tree-updates, each MLS message needs to
transmit node values along the direct path of a leaf.  The path
contains a public key for the leaf node, and a public key and
encrypted secret value for intermediate nodes in the path.  In both
cases, the path is ordered from the leaf to the root; each node MUST
be the parent of its predecessor.
Paragraph (version B):
As described in ratchet-tree-commits, each MLS message needs to
transmit node values along the direct path of a leaf.  The path
contains a public key for the leaf node, and a public key and
encrypted secret value for intermediate nodes in the path.  In both
cases, the path is ordered from the leaf to the root; each node MUST
be the parent of its predecessor.
Paragraph (version A):
The update secret is the value "path_secret[n+1]" derived from
the "path_secret[n]" value associated to the root node.
Paragraph (version A):
Use the update 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):
The "commit_secret" is the value "path_secret[n+1]" derived
from the "path_secret[n]" value associated to the root node.
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 A):
Identify the lowest node at which the direct paths from "index"
and "signer_index" overlap.  Set private keys for that node and
its parents up to the root of the tree, using the "path_secret"
from the KeyPackage and following the algorithm in ratchet-tree-
updates to move up the tree.
Paragraph (version B):
Identify the lowest node at which the direct paths from "index"
and "signer_index" overlap.  Set private keys for that node and
its parents up to the root of the tree, using the "path_secret"
from the KeyPackage and following the algorithm in ratchet-tree-
commits to move up the tree.
Paragraph (version A):
It might be possible, because of the non-contributivity of
intermediate nodes, that update messages could be applied one after
the other without the Delivery Service having to reject any handshake
message, which would make MLS more resilient regarding the
concurrency of handshake 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):
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 handshake
message, which would make MLS more resilient regarding the
concurrency of handshake 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 A):
Here, S may be the "init_secret", "update_secret", "epoch_secret",
"application_secret" as well as any secret in the AS Tree or one of
the ratchets.
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 A):
the "init_secret", "update_secret", "epoch_secret",
"application_secret" of that epoch,
Paragraph (version B):
the "init_secret", "commit_secret", "epoch_secret",
"application_secret" of that epoch,
Paragraph (version A):
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
update_secret and init_secret used to derive G (i.e. the
application_secret).  The client MAY retain (i.e., 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 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 (i.e. the
application_secret).  The client MAY retain (i.e., 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.
Paragraph (version B):
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 Commit 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 Commit operation, it cannot compute any
derived secrets.