Draft: draft-ietf-mls-protocol

Commentary: This PR adds a few more key points to the security considerations that probably deserve to be in this document . 
 Great additions overall ! Just a few nits and questions .
Paragraph (version B):
Because MLS messages are protected at the message level, the
confidentiality and integrity of the group state do not depend on
those messages being protected in transit.  However, an attacker who
can observe those messages and transit will be able to learn about
the group state, including potentially the group membership (see
group-membership below).  Such an attacker might also be able to
mount denial-of-service attacks on the group or exclude new members
by selectively removing messages in transit.  In order to prevent
this form of attack, it is RECOMMENDED that all MLS messages be
carried over a secure transport such as TLS RFC8446 or QUIC RFC9000.
Paragraph (version A):
MLS provides no mechanism to protect the group ID and epoch of a
message from the DS, so the group ID and the frequency of messages
and epoch changes are not protected against inspection by the DS.
Paragraph (version A):
A group's extensions are first set by the group's creator and then
updated by GroupContextExtensions proposals.  A GroupContextExtension
proposal sent as a PublicMessage leaks the groups' extensions.
Paragraph (version B):
MLS provides no mechanism to protect the group ID and epoch of a
message from the DS, so the group ID and the frequency of messages
and epoch changes are not protected against inspection by the DS.
However, any modifications to these will cause decryption failure.
Paragraph (version B):
A group's extensions are first set by the group's creator and then
updated by GroupContextExtensions proposals.  A GroupContextExtension
proposal sent as a PublicMessage leaks the group's extensions.
Paragraph (version A):
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 public keys whose private keys had previously been compromised.
Paragraph (version A):
Forward secrecy between epochs is provided by deleting private keys
from past versions 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 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 public keys whose private keys had previously been compromised.
Note that sending an Update proposal does not achieve PCS until
another member includes it in a Commit.  Members can achieve
immediate PCS by sending their own Commit and populating the "path"
field, as described in commit.  To be clear, in all these cases, the
PCS guarantees come into effect when the members of the group process
the relevant Commit, not when the sender creates it.
Paragraph (version B):
Forward secrecy between epochs is provided by deleting private keys
from past versions 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.  Note that group secrets and message
encryption keys are shared by the group, and thus their is a risk to
forward secrecy as long as any member has not deleted these keys.
This is a particular risk if a member is offline for a long period of
time.  Applications SHOULD have mechanisms for evicting group members
which are offline for too long (e.g., have not changed their key
within some period).
Paragraph (version B):
MLS is designed to protect the confidentiality and integrity of the
group data even in the face of a compromised DS.  However, a
compromised DS can still mount some attacks.  While it cannot forge
messages, it can selectively delay or remove them.  This can in some
cases be observed by detecting gaps in the per-sender generation
counter, though it may not always be possible to distinguish an
attack from message loss.  In addition, the DS can permanently block
messages to and from a group member.  This will not always be
detectable by other members.  If an application uses the DS to
resolve conflicts between simultaneous Commits (see sequencing), it
is also possible for the DS to influence which Commit is applied,
even to the point of preventing a member from ever having its Commits
applied.
Paragraph (version B):
When put together, these abilities potentially allow a DS to collude
with an attacker who has compromised a member's state to defeat PCS
by suppressing the valid Update and Commit messages from the member
that would lock out the attacker and update the member's leaf to a
new, uncompromised state.  Aside from the SenderData.generation
value, MLS leaves loss detection up to the application.
Paragraph (version B):
Authentication Service compromise is much more serious than
compromise of the Delivery Service.  A compromised AS can assert a
binding for a signature key and identity pair of its choice, thus
allowing impersonation of a given user.  This ability is sufficient
to allow the AS to join new groups as if it were that user.
Depending on the application architecture, it may also be sufficient
to allow the compromised AS to join the group as an existing user,
for instance as if it were a new device associated with the same
user.  If the application uses a transparency mechanism such as
CONIKS CONIKS or Key Transparency KT, then it may be possible for end
users to detect this kind of misbehavior by the AS.  It is also
possible to construct schemes in which the various clients owned by a
user vouch for each other, e.g., by signing each others' keys.
Paragraph (version A):
Applications can address this risk by requiring certain members of
the group to acknowledge successful processing of a Commit before the
group regards the Commit as accepted.  The minimum set of
acknowledgements necessary to verify that a Commit is well-formed
comprises an acknowledgement from one member per node in the
UpdatePath, that is, one member from each subtree rooted in the
copath node corresponding to the node in the UpdatePath.
Paragraph (version B):
Applications can address this risk by requiring certain members of
the group to acknowledge successful processing of a Commit before the
group regards the Commit as accepted.  The minimum set of
acknowledgements necessary to verify that a Commit is well-formed
comprises an acknowledgement from one member per node in the
UpdatePath, that is, one member from each subtree rooted in the
copath node corresponding to the node in the UpdatePath.  MLS does
not provide a built-in mechanism for such acknowledgements, but they
can be added at the application layer.