Draft: draft-ietf-mls-protocol

Commentary: This PR reflects a concrete scheme on top of that implements the authentication framework discussed on the list recently . There are a few major changes : Defines a structure that is incorporated into the key schedule and signatures Adds a message that provisions a new member with roster and tree information Removes the Merkle tree over group identities ( and related definitions ) , since all participants now keep the full roster 
 We talked about quite a number of different ways to do deletion in * ART groups . Give at least a high - level overview of the main ones , and mention their pros and cons . These include : just rebuild the tree  : simple , easy , no extra operations  : inefficient , puts the deleter in a trusted position in the group until every remaining member has updated update deletee 's key to blank  : fairly simple , no extra operations  : puts the deleter in a trusted position until the sibling or cousin of the deletee has updated send a delete secret over pairwise channels Pros : no trusted positions  : O(N ) , leaves a potentially - compromised leaf node in the tree send a delete secret by KEMing to everyone else Pros : no trusted positions , efficient  : leaves a potentially - compromised leaf node in the tree , multiple deletes interact in a complex way 
 I do n't quite follow the deletion algorithm that 's in there at the moment . Does it require double - join bookkeeping , If so I can add a note about that . 
 I 'm going to look at clarifying deletion in the doc ; but essentially we 're going for replace - then - blank in this initial draft . Keeping punctured trees is an option we should discuss once it 's out there . 
 I think the algorithm in is explicitly double - joined . When I get time , I 'll file another PR to move to the delete - without - double - join algorithm I posted to the list ( i.e. , puncture the tree ) . 
 Since we 're no longer using  , I think this issue is no longer relevant . 
 I think the overall direction seems good . Have few nits overall , but given we will be discussing the content at the interim , LGTM
Paragraph (version B):
RFC EDITOR PLEASE DELETE THIS SECTION.
Paragraph (version B):
Initial adoption of draft-barnes-mls-protocol-01 as a WG item.
Paragraph (version A):
Terminology specific to tree computations is described in binary-
trees.
Paragraph (version B):
Terminology specific to tree computations is described in ratchet-
trees.
Paragraph (version A):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download an InitKey for a new participant and
broadcast an Add which the current group can use to update their
state and the new participant can use to initialize its state.
Paragraph (version B):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download an InitKey for a new participant and
broadcast an Add message that the current group can use to update
their state and the new participant can use to initialize its state.
Paragraph (version A):
Users are deleted 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 Delete message that adds new entropy to the
group state that is known to all members except the deleted member.
After other participants have processed this message, the group's
secrets will be unknown to the deleted 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):
Merkle trees for efficiently committing to a set of group
participants.
Paragraph (version A):
Ratchet trees for deriving shared secrets among this group of
participants.
Paragraph (version A):
The two trees in the protocol share a common structure, allowing us
to maintain a direct mapping between their nodes when manipulating
group membership.  The "nth" leaf in each tree is owned by the "nth"
group participant.
Paragraph (version A):
We use a common set of terminology to refer to both types of binary
tree.
Paragraph (version A):
Trees consist of various different types of _nodes_. A node is a
_leaf_ if it has no children, and a _parent_ otherwise; note that all
parents in our Merkle or ratchet trees have precisely two children, a
_left_ child and a _right_ child.  A node is the _root_ of a tree if
it has no parents, and _intermediate_ if it has both children and
parents.  The _descendants_ of a node are that node, its children,
and the descendants of its children, and we say a tree _contains_ a
node if that node is a descendant of the root of the tree.  Nodes are
_siblings_ if they share the same parent.
Paragraph (version B):
Users 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):
The protocol uses "ratchet trees" for deriving shared secrets among a
group of participants.
Paragraph (version B):
Trees consist of _nodes_. A node is a _leaf_ if it has no children,
and a _parent_ otherwise; note that all parents in our Merkle or
ratchet trees have precisely two children, a _left_ child and a
_right_ child.  A node is the _root_ of a tree if it has no parents,
and _intermediate_ if it has both children and parents.  The
_descendants_ of a node are that node, its children, and the
descendants of its children, and we say a tree _contains_ a node if
that node is a descendant of the root of the tree.  Nodes are
_siblings_ if they share the same parent.
Paragraph (version A):
We extend both types of tree to include a concept of "blank" nodes;
which are used to replace group members who have been removed.  We
expand on how these are used and implemented in the sections below.
Paragraph (version A):
Merkle trees are used to efficiently commit to a collection of group
members.  We require a hash function, denoted H, to construct this
tree.
Paragraph (version A):
The below tree provides an example of a size 2 tree, containing
identity keys "A" and "B".
Paragraph (version A):
In Merkle trees, blank nodes appear only at the leaves.  In
computation of intermediate nodes, they are treated in the same way
as other nodes.
Paragraph (version A):
A proof of a given leaf being a member of the Merkle tree consists of
the value of the leaf node, as well as the values of each node in its
copath.  From these values, its path to the root can be verified;
proving the inclusion of the leaf in the Merkle tree.
Paragraph (version A):
In the below tree, we denote with a star the Merkle proof of
membership for leaf node "A".  For brevity, we notate "Hash(0x02 ||
A || B)" as "AB".
Paragraph (version A):
Nodes in a ratchet tree can have a special value "_", used to
indicate that the node should be ignored during path computations.
Such nodes are used to replace leaves when participants are deleted
from the group.
Paragraph (version A):
Replacing a node by _ in TreeKEM, means performing an update on any
leaf without sending the new key to the the blanked leaf.  In the
following example, participant A update its key to A' and derive the
new sequence of keys up-to the path.  Here A only send H(H(A')) to
the parent node of C and D but does not send H(A') to B which evicts
it from the Group.
Paragraph (version A):
If two sibling nodes are both _, their parent value also becomes _.
Paragraph (version A):
Blank nodes effectively result in an unbalanced tree, but allow the
tree management to behave as for a balanced tree for programming
simplicity.
Paragraph (version A):
Since a group can evolve over time, a session logically comprises a
sequence of states.  The time in which each individual state is used
is called an "epoch", and each state is assigned an epoch number that
increments when the state changes.
Paragraph (version A):
MLS handshake messages provide each node with enough information
about the trees to authenticate messages within the group and compute
the group secrets.
Paragraph (version B):
A member of a group authenticates the identities of other
participants by means of credentials issued by some authentication
system, e.g., a PKI.  Each type of credential MUST express the
holder's identity as well as the public key of a signature key pair
that the holder of the credential will use to sign MLS messages.
Credentials MAY also include information that allows a relying party
to verify the identity / signing key binding.
Paragraph (version B):
The "group_id" field is an application-defined identifier for the
group.
Paragraph (version B):
The "epoch" field represents the current version of the group key.
Paragraph (version B):
The "tree" field contains the public keys corresponding to the
nodes of the ratchet tree for this group.  The length of this
vector MUST be "2*size + 1", where "size" is the length of the
roster, since this is the number of nodes in a tree with "size"
leaves, according to the structure described in ratchet-trees.
Paragraph (version B):
The "transcript" field contains the list of "GroupOperation"
messages that led to this state.
Paragraph (version B):
When a new member is added to the group, an existing member of the
group provides the new member with a Welcome message.  The Welcome
message provides the information the new member needs to initialize
its GroupState.
Paragraph (version A):
The derivation of the update secret depends on the change being made,
as described below.
Paragraph (version A):
For Add, the new user does not know the prior epoch init secret.
Instead, entropy from the prior epoch is added via the update secret,
and an all-zero vector with the same length as a hash output is used
in the place of the init secret.
Paragraph (version A):
In order to facilitate asynchronous addition of participants to a
group, it is possible to pre-publish initialization keys that provide
some public information about a user or group.  UserInitKey messages
provide information about a potential group member, that a group
member can use to add this user to a group asynchronously.
Paragraph (version A):
An MLS handshake message encapsulates a specific message that
accomplishes a change to the group state.  It also includes a
signature by a member of the group, together with a Merkle inclusion
proof that demonstrates that the signer is a legitimate member of the
group.
Paragraph (version A):
Before considering a handshake message valid, the recipient MUST
verify both that the signature is valid, the Merkle inclusion proof
is valid, and the sender is authorized to make the change according
to group policy.  The input to the signature computations comprises
the entire handshake message except for the signature field.
Paragraph (version A):
The Merkle tree head to be used for validating the inclusion proof
MUST be one that the recipient trusts to represent the current list
of participant identity keys.
Paragraph (version B):
An MLS handshake message encapsulates a specific "key exchange"
message that accomplishes a change to the group state.  It also
includes a signature by the sender of the message over the GroupState
object representing the state of the group after the change has been
made.
Paragraph (version B):
Verify that the "prior_epoch" field of the Handshake message is
equal the "epoch" field of the current GroupState object.
Paragraph (version B):
Use the "operation" message to produce an updated GroupState
object incorporating the proposed changes.
Paragraph (version B):
If the signature verifies successfully, consider the updated
GroupState object as the current state of the group.
Paragraph (version A):
An Add message is sent by a group member to add a new participant to
the group.
Paragraph (version A):
The public key of the ephemeral key pair is placed in the "ephemeral"
field of the Add message.  The computed direct path is placed in the
"add_path" field.
Paragraph (version B):
Since the new member is expected to process the Add message for
itself, the Welcome message should reflect the state of the group
before the new user is added.  The sender of the Welcome message can
simply copy all fields except the "leaf_secret" from its GroupState
object.
Paragraph (version B):
The generated leaf secret is placed in the "leaf_secret" field of the
Welcome message.  The direct path and the UserInitKey are placed
their respective fields in the Add message.
Paragraph (version A):
In TreeKEM, because of the non-contributivity of intermediate nodes
update messages can be applied one after the other without the
Delivery Service having to reject any handshake message which makes
TreeKEM 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
deletes.
Paragraph (version B):
In TreeKEM, because of the non-contributivity of intermediate nodes
update messages can be applied one after the other without the
Delivery Service having to reject any handshake message which makes
TreeKEM 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):
The primary purpose of this protocol is to enable an authenticated
group key exchange among participants.  In order to protect messages
sent among those participants, an application will need to specify
how messages are protected.
Paragraph (version A):
For every epoch, the root key of the ratcheting tree can be used to
derive key material for symmetric operations such as encryption/AEAD
and MAC; AEAD or MAC MUST be used to ensure that the message
originated from a member of the group.
Paragraph (version A):
In addition, asymmetric signatures SHOULD be used to authenticate the
sender of a message.
Paragraph (version A):
The requirement for this is that all participants know these values.
If additional clear-text fields are attached to messages (like the
counter), those fields MUST be protected by a signed message
envelope.
Paragraph (version A):
Alternatively, the hash of the previous message can also be included
as an additional field rather than change the encryption key.  This
allows for a more flexible approach, because the receiving party can
choose to ignore it (if the value is not known, or if transcript
security is not required).
Paragraph (version A):
The security goals of MLS are described in .
We describe here how the protocol achieves its goals at a high level,
though a complete security analysis is outside of the scope of this
document.
Paragraph (version B):
The primary purpose of the handshake protocol is to provide an
authenticated group key exchange to participants.  In order to
protect Application messages sent among those participants, the
Application secret provided by the Handshake key schedule is used to
derive encryption keys for the Message Protection Layer.
Paragraph (version B):
Application messages MUST be protected with the Authenticated-
Encryption with Associated-Data (AEAD) encryption scheme associated
with the MLS ciphersuite.  Note that "Authenticated" in this context
does not mean messages are known to be sent by a specific participant
but only from a legitimate member of the group.  To authenticate a
message from a particular member, signatures are required.  Handshake
messages MUST use asymmetric signatures to strongly authenticate the
sender of a message.
Paragraph (version B):
Each participant maintains their own chain of Application secrets,
where the first one is derived based on a secret chained from the
Epoch secret.  As shown in key-schedule, the initial Application
secret is bound to the identity of each participant to avoid
collisions and allow support for decryption of reordered messages.
Paragraph (version B):
Subsequent Application secrets MUST be rotated for each message sent
in order to provide stronger cryptographic security guarantees.  The
Application Key Schedule use this rotation to generate fresh AEAD
encryption keys and nonces used to encrypt and decrypt future
Application messages.  In all cases, a participant MUST NOT encrypt
more than expected by the security bounds of the AEAD scheme used.
Paragraph (version B):
Note that each change to the Group through a Handshake message will
cause a change of the Group Secret.  Hence this change MUST be
applied before encrypting any new Application message.  This is
required for confidentiality reasons in order for Members to avoid
receiving messages from the group after leaving, being added to, or
excluded from the Group.
Paragraph (version B):
Note that [sender] represent the uint32 value encoding the index of
the participant in the ratchet tree.
Paragraph (version B):
The Application context provided together with the previous
Application secret is used to bind the Application messages with the
next key and add some freshness.
Paragraph (version B):
Senders MUST only use the Application Secret once and
monotonically increment the generation of their secret.  This is
important to provide Forward Secrecy at the level of Application
messages.  An attacker getting hold of a Participant's Application
Secret at generation [N+1] will not be able to derive the
Participant's Application Secret [N] nor the associated AEAD key
and nonce.
Paragraph (version B):
Receivers MUST delete an Application Secret once it has been used
to derive the corresponding AEAD key and nonce as well as the next
Application Secret.  Receivers MAY keep the AEAD key and nonce
around for some reasonable period.
Paragraph (version B):
Receivers MUST delete AEAD keys and nonces once they have been
used to successfully decrypt a message.
Paragraph (version B):
The length of the key being generated.
Paragraph (version B):
Note, that because the identity of the participant using the keys to
send data is included in the initial Application Secret, all
successive updates to the Application secret will implicitly inherit
this ownership.
Paragraph (version B):
All the traffic keying material is recomputed whenever the underlying
Application Secret changes.
Paragraph (version B):
The Group identifier and epoch allow a device to know which Group
secrets should be used and from which Epoch secret to start computing
other secrets and keys.  The participant identifier is used to derive
the participant Application secret chain from the initial shared
Application secret.  The application generation field is used to
determine which Application secret should be used from the chain to
compute the correct AEAD keys before performing decryption.
Paragraph (version B):
The signature used in the MLSPlaintext is computed over the
MLSSignatureContent which covers the metadata information about the
current state of the group (group identifier, epoch, generation and
sender's Leaf index) to prevent Group participants from impersonating
other participants.  It is also necessary in order to prevent cross-
group attacks.
Paragraph (version B):
Similarly to TLS 1.3, if padding is used, the MLS messages MUST be
padded with zero-valued bytes before AEAD encryption.  Upon AEAD
decryption, the length field of the plaintext is used to compute the
number of bytes to be removed from the plaintext to get the correct
data.  As the padding mechanism is used to improve protection against
traffic analysis, removal of the padding SHOULD be implemented in a
"constant-time" manner at the MLS layer and above layers to prevent
timing side-channels that would provide attackers with information on
the size of the plaintext.
Paragraph (version B):
Since each Application message contains the Group identifier, the
epoch and a message counter, a participant can receive messages out
of order.  If they are able to retrieve or recompute the correct AEAD
decryption key from currently stored cryptographic material
participants can decrypt these messages.
Paragraph (version B):
For usability, MLS Participants might be required to keep the AEAD
key and nonce for a certain amount of time to retain the ability to
decrypt delayed or out of order messages, possibly still in transit
while a decryption is being done.
Paragraph (version B):
The security goals of MLS are described in [I-D.ietf-mls-
architecture].  We describe here how the protocol achieves its goals
at a high level, though a complete security analysis is outside of
the scope of this document.