Draft: draft-ietf-mls-protocol

Commentary: I went back and watched the recording of the last interim to get some context for this PR , and the motivation given there is n't entirely clear to me . The reasoning given then was : We want to allow rotation of identity key . This helps authenticate the leaf key by signing it . But if we want to allow rotating the identity key , what we need is an operation that changes the field of the leaf . Putting the entire CIK in the leaf does n't help that . And I imagine that the leaf key would already be signed by the changes required for . 
 Note that this PR will need to change Commit as well -- the DirectPath in the commit sets the HPKEPublicKey in the sender 's leaf node . Suggested fix : DirectPath so that the first node in the path is the one above the leaf ( not the leaf itself ) a new ClientInitKey field to Commit that replaces the leaf That 's also forward - compatible with hash - based solutions to tree signing ( cf . ) , since we can just define a ClientInitKey extension that contains the hash to be signed . 
 To answer my own question , putting the entire CIK in the leaf ( instead of just , say , a single signature ) means the ratchet tree will contain information about node capabilities . This makes it possible for members being to a group to detect downgrade attacks . 
  and I noticed that the expiration can be omitted on a last resort key . Discuss this as it does n't seem to be a good idea , maybe a long expiration time is better ... This is also related to have the expiration extension mandatory or not . Because we are planning signature key rotation in we may not have to enforce an expiration of the last resort key , but it somehow feels dangerous . 
 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 .
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 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 A):
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):
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 and its member information.  Any
member can update this information at any time by generating a fresh
ClientInitKey and sending a Commit message.  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 Commit messages.  This policy could require a Commit with
each message, or require sending an update regularly.
Paragraph (version A):
No participant in an MLS group has full knowledge of the secret state
of the tree, i.e., private keys associated to the nodes.  Instead,
each member is assigned to a leaf of the tree, which determines the
set of secret state known to the member.  The credential stored at
that leaf is one provided by the member.
Paragraph (version B):
No participant in an MLS group has full knowledge of the secret state
of the tree, i.e., private keys associated with the nodes.  Instead,
each member is assigned to a leaf of the tree, which determines the
set of secret state known to the member.  The credential stored at
that leaf is one provided by the member.
Paragraph (version A):
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 B):
When performing a Commit, the leaf ClientInitKey of the commiter and
its direct path to the root are updated with new secret values.  The
HPKE leaf public key within the ClientInitKey MUST be a freshly
generated value to provide better Post-Compromise Secrecy.
Paragraph (version B):
The generator of the Commit starts by using the HPKE secret key
"leaf_hpke_secret_key" associated with the new leaf ClientInitKey
(see initialization-keys) to compute "path_secret[0]" and generate a
sequence of "path secrets", one for each ancestor of its leaf.  That
is, path_secret[0] is used for the node directly above 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):
Note that each new credential that has not already been validated by
the application SHOULD be validated against the Authentication
Service.
Paragraph (version A):
To allow group members to verify that they agree on the cryptographic
state of the group, this section defines a scheme for generating a
hash value that represents the contents of the group's ratchet tree
and the members' credentials.
Paragraph (version A):
The "public_key" and "credential" fields represent the leaf public
key and the credential for the member holding that leaf,
respectively.  The "info" field is equal to the null optional value
when the leaf is blank (i.e., no member occupies that leaf).
Paragraph (version B):
Note that each new credential that has not already been validated by
the application MUST be validated against the Authentication Service.
Paragraph (version B):
In order to facilitate asynchronous addition of clients to a group,
it is possible to pre-publish initialization keys that provide some
public information about a user.  ClientInitKey structures provide
information about a client that any existing member can use to add
this client to the group asynchronously.
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 can be updated throughout
the lifetime of the group by sending a new ClientInitKey with a new
identity; the new identity MUST be validated by the authentication
service.  ClientInitKeys 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 credential
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):
The value for hpke_init_key MUST be a public key for the asymmetric
encryption scheme defined by cipher_suite.  The whole structure is
signed using the client's identity key.  A ClientInitKey object with
an invalid signature field MUST be considered malformed.  The input
to the signature computation comprises all of the fields except for
the signature field.
Paragraph (version B):
As the "ClientInitKey" is a structure which is stored in the Ratchet
Tree and updated depending on the evolution of this tree, each
modification of its content MUST be reflected by a change of its
signature.  This allow other members to control the validity of the
ClientInitKey at any time and in particular in the case of a newcomer
joining the group.
Paragraph (version B):
To allow group members to verify that they agree on the public
cryptographic state of the group, this section defines a scheme for
generating a hash value that represents the contents of the group's
ratchet tree and the members' ClientInitKeys.
Paragraph (version B):
The content within the leaf of a ratchet tree is composed of a
"ClientInitKey" when the leaf is populated.  The "info" field is
equal to the null optional value when the leaf is blank (i.e., no
member occupies that leaf).
Paragraph (version A):
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 length of the "encrypted_path_secret" vector MUST be zero for the
first node in the path.  For the remaining elements in the vector,
the number of ciphertexts in the "encrypted_path_secret" vector MUST
be equal to the length of the resolution of the corresponding copath
node.  Each ciphertext in the list is the encryption to the
corresponding node in the resolution.
Paragraph (version B):
As described in ratchet-tree-commits, each MLS message needs to
transmit a ClientInitKey leaf and node values along its direct path.
The path contains a public key and encrypted secret value for all
intermediate nodes in the path above the leaf.  The path is ordered
from the closest node to the leaf to the root; each node MUST be the
parent of its predecessor.
Paragraph (version B):
The number of ciphertexts in the "encrypted_path_secret" vector MUST
be equal to the length of the resolution of the corresponding copath
node.  Each ciphertext in the list is the encryption to the
corresponding node in the resolution.
Paragraph (version A):
The security level associated to the PSK injected in the key schedule
SHOULD match at least the security level of the ciphersuite in use in
the group.
Paragraph (version B):
The security level associated with the PSK injected in the key
schedule SHOULD match at least the security level of the ciphersuite
in use in the group.
Paragraph (version A):
In order to facilitate asynchronous addition of clients to a group,
it is possible to pre-publish initialization keys that provide some
public information about a user.  ClientInitKey messages provide
information about a client that any existing member can use to add
this client to the group asynchronously.
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 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):
The value for init_key MUST be a public key for the asymmetric
encryption scheme defined by cipher_suite.  The whole structure is
signed using the client's identity key.  A ClientInitKey object with
an invalid signature field MUST be considered malformed.  The input
to the signature computation comprises all of the fields except for
the signature field.
Paragraph (version A):
In principle, the above process could be streamlined by having the
creator directly create a tree and choose a random value for first
epoch's epoch secret.  We follow the steps above because it removes
unnecessary choices, by which, for example, bad randomness could be
introduced.  The only choices the creator makes here are its own HPKE
key and credential, the leaf secret from which the Commit is built,
and the intermediate key pairs along the direct path to the root.
Paragraph (version B):
In principle, the above process could be streamlined by having the
creator directly create a tree and choose a random value for first
epoch's epoch secret.  We follow the steps above because it removes
unnecessary choices, by which, for example, bad randomness could be
introduced.  The only choices the creator makes here are its own
ClientInitKey, the leaf secret from which the Commit is built, and
the intermediate key pairs along the direct path to the root.
Paragraph (version A):
An Update proposal requests that the sender's leaf node in the tree
be updated with a new HPKE public key.
Paragraph (version B):
An Update proposal is a similar mechanism to Add with the distinction
that it is the sender's leaf ClientInitKey in the tree which would be
updated with a new ClientInitKey.
Paragraph (version A):
The sender of a Commit message MUST include in it all valid Proposals
that the sender has received during the current epoch.  Invalid
Proposals include, for example, Proposals with an invalid signature
or Proposals that are semantically inconsistent, such as a Remove
proposal for an unoccupied leaf.  The Commit MUST NOT combine
Proposals sent within different epochs.  Despite these requirements,
it is still possible for a valid Proposal not to be covered by a
Commit, e.g., because the sender of the Commit did not receive the
Proposal.  In such cases, the sender of the proposal can retransmit
the Proposal in the new epoch.
Paragraph (version B):
The sender of a Commit message MUST include in it all valid Proposals
that the sender has received during the current epoch.  Invalid
Proposals include, for example, Proposals with an invalid signature
or Proposals that are semantically inconsistent, such as a Remove
proposal for an unoccupied leaf.  The Commit MUST NOT combine
Proposals sent within different epochs.  Despite these requirements,
it is still possible for a valid Proposal not to be covered by a
Commit, e.g., because the sender of the Commit did not receive the
Proposal.  In such cases, the sender of the proposal can retransmit
the Proposal in the new epoch.  In the case where a committer is
processing Proposals where an Update proposal or a Remove proposal
exists for herself, this proposal MUST be ignored and added to the
list of discarded proposals in the Commit.
Paragraph (version A):
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):
The "commit_secret" is the value "path_secret[n+1]" derived
from the "path_secret[n]" value associated with the root node.
Paragraph (version A):
In the description of the tree as a list of nodes, the "credential"
field for a node MUST be populated if and only if that node is a leaf
in the tree (i.e., a node with an even index).
Paragraph (version B):
In the description of the tree as a list of nodes, the
"client_init_key" field for a node MUST be populated if and only if
that node is a leaf in the tree.