Draft: draft-ietf-mls-protocol

Commentary: Security considerations has gotten a little outdated . Updated with new info
Paragraph (version A):
Group secrets are derived from (i) previous group secrets, and (ii)
the root key of a ratcheting tree.  Only group members know their
leaf private key in the group, therefore, the root key of the group's
ratcheting tree is secret and thus so are all values derived from it.
Paragraph (version A):
Initial leaf keys are known only by their owner and the group
creator, because they are derived from an authenticated key exchange
protocol.  Subsequent leaf keys are known only by their owner.
Paragraph (version A):
Note that the signature keys used by the protocol MUST be distributed
by an "honest" authentication service for clients to authenticate
their legitimate peers.
Paragraph (version A):
There are two forms of authentication we consider.  The first form
considers authentication with respect to the group.  That is, the
group members can verify that a message originated from one of the
members of the group.  This is implicitly guaranteed by the secrecy
of the shared key derived from the ratcheting trees: if all members
of the group are honest, then the shared group key is only known to
the group members.  By using AEAD or appropriate MAC with this shared
key, we can guarantee that a member in the group (who knows the
shared secret key) has sent a message.
Paragraph (version A):
The second form considers authentication with respect to the sender,
meaning the group members can verify that a message originated from a
particular member of the group.  This property is provided by digital
signatures on the messages under signature keys.
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 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 a Commit operation, it cannot compute any
derived secrets.
Paragraph (version A):
In the case where the client could have been compromised (device
loss, for example), the client SHOULD signal the delivery service to
expire all the previous KeyPackages and publish fresh ones for PCS.
Paragraph (version B):
Group secrets are partly derived from the output of a ratchet tree.
Ratchet trees work by assigning each member of the group to a leaf in
the tree and maintaining the following property: the private key of a
node in the tree is known only to members of the group that are
assigned a leaf in the node's subtree.  This is called the _ratchet
tree invariant_ and it makes it possible to encrypt to all group
members except one, with a number of ciphertexts that's logarithmic
in the number of group members.
Paragraph (version B):
The ability to efficiently encrypt to all members except one allows
members to be securely removed from a group.  It also allows a member
to rotate their keypair such that the old private key can no longer
be used to decrypt new messages.
Paragraph (version B):
The first form of authentication we provide is that group members can
verify a message originated from one of the members of the group.
For encrypted messages, this is guaranteed because messages are
encrypted with an AEAD under a key derived from the group secrets.
For plaintext messages, this is guaranteed by the use of a
"membership_tag" which constitutes a MAC over the message, under a
key derived from the group secrets.
Paragraph (version B):
The second form of authentication is that group members can verify a
message originated from a particular member of the group.  This is
guaranteed by a digital signature on each message from the sender's
identity key.
Paragraph (version B):
Post-compromise security is provided between epochs by members
regularly updating their leaf key in the ratchet tree.  Updating
their leaf key prevents group secrets from continuing to be encrypted
to previously compromised public keys.
Paragraph (version B):
Forward-secrecy between epochs is provided by deleting private keys
from past version of the ratchet tree, as this prevents old group
secrets from being re-derived.  Forward secrecy _within_ an epoch is
provided by deleting message encryption keys once they've been used
to encrypt or decrypt a message.
Paragraph (version B):
Post-compromise security is also provided for new groups by members
regularly generating new InitKeys and uploading them to the Delivery
Service, such that compromised key material won't be used when the
member is added to a new group.