Draft: draft-ietf-mls-architecture

Commentary: There is no glossary or terminology section at the beginning of the architecture draft . I think that is fine , but I think explaining that " messaging " does n't mean instant messaging , and what client and member mean in the Introduction or the first part of the General Setting would be useful . 
 Fixed in 
 Comment by I find RECOMMENDATION : not friendly to read , the " * " distract from the actual capitalization of the important of RECOMMENDATION : I understand this is a tooling issue , perhaps it can be addressed later ? Maybe : Different clients of the same or different user might support different protocol versions and ciphersuites . [ CAPBR ] is not a proper reference Reads a little odd , why not use t1 and t2 ? I can not confirm neither deny that I do n't not understand this an legitimate client -a legitimate client either " by an " , or by mechanisms ( plural ) a DS can mount a variety of DoS attacks -a malicious DS .... This sentence does not parse for me Pet peeve : vis - a - vis -- This is not a friendly language construct , especially for people whose first language is n't English ( or Latin , but those should all be dead by now ) to extract the top - level signature key . -to extract the top - level signature private key . One thing for which the MLS Protocol is designed for is -One design feature of the MLS protocol is Please rewrite this without using the word " facultative " . Maybe use " essential " or " key element " or something ? TOFU - Expand on its first ( and only ) use . fanout - Not a fan of the word fanout , but at least it is explained in the draft Missing the word " decrypted " ? another hard to parse sentence : Perhaps " to gain the ability of ..... " ? avoid double negative : Maybe " to limit privacy risks " ? 
 Comment by This should have been told to the reader WAY before in the document , before it starts mentioning clients and users and devices . 
 Comment by Similarly , I feel I am missing context here . Why is minimum important , why need more than one ? What is the definition of request ? 
 I think fixing will fix this as well , namely that a member wishing to add a client will request a KeyPackage for that client . 
 Comment by What about different extensions ? One client might be able to display images , while the other can not ? Is that not possible , or was it just not listed here ? 
 It is supported , modulo the group extension . I do n't care whether it 's listed here or not . 
 Looking at this more in context -- versions and ciphersuites are different from extensions in this context because each KeyPackage can only express support for one version and ciphersuite . 
 Comment by It feels I am missing some context here . Who or whom is this KeyPackage served too ? 
 A KeyPackage is downloaded by a client that wants to add the holder of the KeyPackage to a group . Probably worth a sentence here adding that context . 
 Comment by The use of client , member and someone / everyone is a little inconsistent , eg see : I assume a member is identical to a client , but is a member of the group . But then the above " clients may wish to do the following : " should not be used with " remove one or more members from an existing group ; " Perhaps just adding a line saying " a member is a client that is within a group " might be useful ? Or say that client and member are used interchangably , but that a client could be no member of any group ? I guess this is further explained in afterwards . It might be better to bring this up a little earlier ? 
 Yes , I think bringing forward " a member is a client that is within a group " would be useful . A member can remove another member , and can add a client ( not yet a member ) A ( non - member ) client can remove a member ( via an external remove proposal ) , and can add itself ( via an external commit or external add proposal ) . 
 Comment by It is a little unclear whether this is the entire list of operations supported , or a subset . Maybe make that more explicit ? 
 The only one of these that is not supported directly is leaving . Someone has to remove you .
Informally, a group is a set of users who possibly use multiple
endpoint devices to interact with the Service Provider (SP).  A group
may be as small as two members (the simple case of person to person
messaging) or as large as thousands.
MLS provides a way for _clients_ to form _groups_ within which they
can communicate securely.  For example, a set of users might use
clients on their phones or laptops to join a group and communicate
with each other.  A group may be as small as two clients (e.g., for
simple person to person messaging) or as large as thousands.  A
client that is part of a group is a _member_ of that group.
At the cryptographic level, clients (and by extension members in
groups) have equal permissions.  For instance, any member can add or
remove another client in a group.  This is in contrast to some
designs in which there is a single group controller who can modify
the group.  MLS is compatible with having group administration
restricted to certain users, but we assume that those restrictions
are enforced by the application layer.
At the cryptographic level, clients (and by extension members in
groups) have equal permissions.  For instance, any member can add or
remove another member in a group.  This is in contrast to some
designs in which there is a single group controller who can modify
the group.  MLS is compatible with having group administration
restricted to certain users, but we assume that those restrictions
are enforced by the application layer.
The Delivery Service is responsible for ensuring that each KeyPackage
is only served once, with the possible exception of a "last resort"
KeyPackage that's specially designated by the client to be used
multiple times.  As noted in the previous section, users may own
multiple clients, each with their own keying material.  Clients may
also want to support multiple protocol versions and ciphersuites.  As
such, there may be multiple entries stored by each user for a mix of
protocol versions, ciphersuites, and end-user devices.  The Delivery
Service should provide the minimum number of KeyPackages necessary to
satisfy a request.
When a client wishes to establish a group, it first contacts the
Delivery Service to request a KeyPackage for each other client,
authenticates the KeyPackages using the signature keys, and then uses
those to form the group.
The Delivery Service is responsible for ensuring that each KeyPackage
is only used to add its client to a single group, with the possible
exception of a "last resort" KeyPackage that's specially designated
by the client to be used multiple times.  As noted in the previous
section, users may own multiple clients, each with their own keying
material.  Each KeyPackage is specific to an MLS version and
ciphersuite, but a client may want to offer support for multiple
protocol versions and ciphersuites.  As such, there may be multiple
KeyPackages stored by each user for a mix of protocol versions,
ciphersuites, and end-user devices - in addition to the multiplicity
required to support single-use.
When a client wishes to establish a group or add clients to a group,
it first contacts the Delivery Service to request KeyPackages for
each other client, authenticates the KeyPackages using the signature
keys, and then uses those to add the other clients to the group.
When a client requests a KeyPackage in order to add a user to a
group, the Delivery Service should provide the minimum number of
KeyPackages necessary to satisfy the request.  For example, if the
request specifies the MLS version, the DS might provide one
KeyPackage per supported ciphersuite, even if it has multiple such
KeyPackages to enable the corresponding client to be added to
multiple groups before needing to upload more fresh KeyPackages.
PCS means that if a group member's state is compromised at some time
t but the group member subsequently performs an update at some time
t', then all MLS guarantees apply to messages sent by the member
after time t', and by other members after they have processed the
update.  For example, if an attacker learns all secrets known to
Alice at time t, including both Alice's long-term secret keys and all
shared group keys, but Alice performs a key update at time t', then
the attacker is unable to violate any of the MLS security properties
after the updates have been processed.
PCS means that if a group member's state is compromised at some time
t1 but the group member subsequently performs an update at some time
t2, then all MLS guarantees apply to messages sent by the member
after time t2, and by other members after they have processed the
update.  For example, if an attacker learns all secrets known to
Alice at time t1, including both Alice's long-term secret keys and
all shared group keys, but Alice performs a key update at time t2,
then the attacker is unable to violate any of the MLS security
properties after the updates have been processed.
However, a DS can mount a variety of DoS attacks on the system,
including total DoS attacks (where it simply refuses to forward any
messages) and partial DoS attacks (where it refuses to forward
messages to and from specific clients).  As noted in delivery-
guarantees, these attacks are only partially detectable by clients
without an out-of-band channel.  Ultimately, failure of the DS to
provide reasonable service must be dealt with as a customer service
matter, not via technology.
However, a malicious DS can mount a variety of DoS attacks on the
system, including total DoS attacks (where it simply refuses to
forward any messages) and partial DoS attacks (where it refuses to
forward messages to and from specific clients).  As noted in
delivery-guarantees, these attacks are only partially detectable by
clients without an out-of-band channel.  Ultimately, failure of the
DS to provide reasonable service must be dealt with as a customer
service matter, not via technology.
One thing for which the MLS Protocol is designed for is to make sure
that all clients know who is in the group at all times.  This means
that - if all Members of the group and the Authentication Service are
honest - no other parties than the members of the current group can
read and write messages protected by the protocol for that Group.
Note that when a "basic" Credential is used, the Authentication
Service also needs an out-of-band mechanism to verify the identity
asserted in the Credential.
One important feature of MLS is that all clients know who is in the
group at all times.  This means that - if all Members of the group
and the Authentication Service are honest - no other parties than the
members of the current group can read and write messages protected by
the protocol for that Group.  Note that when a "basic" Credential is
used, the Authentication Service also needs an out-of-band mechanism
to verify the identity asserted in the Credential.
We note, again, that as described prior to that section, the
Authentication Service is facultative to design a working
infrastructure and can be replaced by many mechanisms such as
establishing prior one-to-one deniable channels, gossiping, or using
TOFU for credentials used by the MLS Protocol.
We note, again, that as described prior to that section, the
Authentication Service may not be a centralized system, and could be
realized by many mechanisms such as establishing prior one-to-one
deniable channels, gossiping, or using trust on first use (TOFU) for
credentials used by the MLS Protocol.
Often, expectation from users is that the infrastructure will not
retain the ability to constantly map the user identity to signature
public keys of the MLS protocol.  Some infrastructures will keep a
mapping between signature public keys of clients and user identities.
This can benefit an adversary that has compromised the AS (or
required access according to regulation) the ability of monitoring
unencrypted traffic and correlating the messages exchanged within the
same group.
Often, expectation from users is that the infrastructure will not
retain the ability to constantly map the user identity to signature
public keys of the MLS protocol.  Some infrastructures will keep a
mapping between signature public keys of clients and user identities.
This can enable an adversary that has compromised the AS (or required
access according to regulation) to monitor unencrypted traffic and
correlate the messages exchanged within the same group.