Draft: draft-ietf-mls-protocol

Commentary: Add a paragraph to Operational Context describing additional security services that the DS can provide Add a citation to security analyses via the MLS Architecture Add a section discussing metadata protection 
 It also feels like the text assumes that the DS is a server as opposed to the abstract layer that we define it as in the architecture document . Maybe we should qualify the considerations accordingly ? 
 - Thanks for sending . I did n't merge it directly , but rewrote the  section trying to hit the key points from your proposal .  what you think . 
 Comment by     . RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help . 
 CC for citations 
 They are also in this architecture document PR : 
 Oh good , I 'll just add a citation over to mls - architecture . 
 Comment by That is quite some information that must be publicly available to allow external Add requests . This leaks information , eg same epoch means the group membership did not change , etc etc . I hope this will appear in the Security Considerations later :) 
 I suppose between this and , we should add a subsection to the Security Considerations on metadata privacy . 
 I 'm not sure actually resolves this ? 
 Oops , that 's correct Had it in my notes among the others . 
 Comment by There seems to be no group " owner " , so inviting one member X , could that member than delete members from the group until the group is empty ? Apparently , there is ACLs for this , but the document does n't describe how ACLS would work or how these would be implemented . 
 You are correct that MLS is " egalitarian " by default , in that any member can perform any action . This capability can be limited by policy , enforced either at the endpoints or at the DS ( the latter requiring handshake messages to be unencrypted ) . This is discussed in the MLS architecture document , e.g. , in the section . I would be open to adding some security considerations noting this . But seeing as it 's already in the architecture , I would be inclined to close this issue with no action . 
 Comment by I find the interaction with the application layer not clear . Not much is mentioned in this document . How can a group have an administrator ? How is that enforced at the MLS layer ? How do ACLs interact with MLS ? ( How are DoS attacks mitigated ( eg spam attempts to join any group ) . What hooks would be in the authentication service and/or delivery server ? How would clients know the properties of these two services ? This includes how it is not clear to me how race conditions are handled . What if two members try to expel each other at the same time ? What if the group is so large , members always get their epoch wrong for things like Commit messages ? 
 I think the intent was to have these issues mostly dealt with in the architecture document . Broadly speaking , it is the DS 's job to solve these problems . For example , the DS we use in Webex chooses which member makes which commit . This is why we have Section 3 , . There are also some brief notes in Section 14 , " . Unless we need to make this division of labor clearer , I 'm inclined to close this issue with no action . 
 While instant messaging was one of the big motivators for MLS , it is not the only one to be implemented in the same timeframe . In  for example we are planning to have a whole work item that specifies many more constraints on how the DS would be expected to work in an instant messaging context . Whereas we have implementors of MLS who are planning to do things very differently for an IoT communication application . 
 I 'll reread the architecture bit again about the DS , but it still feels to me it could be made more clear .
Paragraph (version A):
An Authentication Service that enables group members to
authenticate the credentials presented by other group members.
Paragraph (version B):
An Authentication Service (AS) that enables group members to
authenticate the credentials presented by other group members.
Paragraph (version B):
The DS and AS may also apply additional policies to MLS operations to
obtain additional security properties.  For example, MLS enables any
participant to add or remove members of a group; a DS could enforce a
policy that only certain members are allowed to perform these
operations.  MLS authenticates all members of a group; a DS could
help ensure that only clients with certain types of credential are
admitted.  MLS provides no inherent protection against denial of
service; A DS could also enforce rate limits in order to mitigate
these risks.
Paragraph (version A):
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.
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.  The Security Considerations section of I-D.ietf-mls-
architecture provides some citations to detailed security analyses.
Paragraph (version B):
The only mechanism MLS provides for confidentially distributing a
group's ratchet tree to new members is to send it in a Welcome
message as a "ratchet_tree" extension.  If an application distributes
the tree in some other way, its security will depend on that
application mechanism.
Paragraph (version B):
In the remainder of this section, we note the ways that the above
properties of the group are reflected in unprotected group messages,
as a guide to understanding how they might be exposed or protected in
a given application.
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.
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 MLSPlaintext leaks the groups' extensions.
Paragraph (version B):
A new member learns the group's extensions via a GroupInfo object.
When the new member joins via a Welcome message, the Welcome
message's encryption protects the GroupInfo message.  When the new
member joins via an external join, they must be provided with a
GroupInfo object.  Protection of this GroupInfo object is up to the
application - if it is transmitted over a channel that is not
confidential to the group and the new joiner, then it will leak the
group's extensions.
Paragraph (version B):
The group's membership is represented directly by its ratchet tree,
since each member's LeafNode contains members' cryptographic keys, a
credential that contains information about the member's identity, and
possibly other identifiers.  Applications that expose the group's
ratchet tree outside the group also leak the group's membership.
Paragraph (version B):
Changes to the group's membership are made by means of Add and Remove
proposals.  If these proposals are sent as MLSPlaintext, then
information will be leaked about the corresponding changes to the
group's membership.  A party that sees all of these changes can
reconstruct the group membership.
Paragraph (version B):
Welcome messages contain a hash of each KeyPackage for which the
Welcome message is encrypted.  If a party has access to a pool of
KeyPackages and observes a Welcome message, then they can identify
the KeyPackage representing the new member.  If the party can also
associate the Welcome with a group, then the party can infer that the
identified new member was added to that group.
Paragraph (version B):
Note that these information leaks reveal the group's membership only
to the degree that that membership is revealed by the contents of a
member's LeafNode in the ratchet tree.  In some cases, this may be
quite direct, e.g., due to credentials attesting to identifiers such
as email addresses.  An application could construct a member's leaf
node to be less identifying, e.g., by using a pseudonymous credential
and frequently rotating encryption and signature keys.