Draft: draft-ietf-mls-architecture

Commentary: Mostly lowercase everything and fixes a few misuses of " member " that were to restrictive .
A Group using a Messaging Service (MS) comprises a set of
participants called Members where each Member is typically expected
to own multiple devices, called Clients.  A group may be as small as
two members (the simple case of person to person messaging) or as
large as thousands.  In order to communicate securely, Group Members
initially use services at their disposal to obtain the necessary
secrets and credentials required for security.
A Group using a Messaging Service (MS) comprises a set of
participants called Members where each member is typically expected
to own multiple devices, called Clients.  A group may be as small as
two members (the simple case of person to person messaging) or as
large as thousands.  In order to communicate securely, clients
initially use services at their disposal to obtain the necessary
secrets and credentials required for security.
A Delivery Service (DS) which is responsible for receiving and
redistributing messages between group members.  In the case of
group messaging, the delivery service may also be responsible for
acting as a "broadcaster" where the sender sends a single message
to a group which is then forwarded to each recipient in the group
by the DS.  The DS is also responsible for storing and delivering
initial public key material required in order to proceed with the
group secret key establishment process.
A Delivery Service (DS) which is responsible for receiving and
redistributing messages between group members.  In the case of
group messaging, the delivery service may also be responsible for
acting as a "broadcaster" where the sender sends a single message
to a group which is then forwarded to each recipient in the group
by the DS.  The DS is also responsible for storing and delivering
initial public key material required by clients in order to
proceed with the group secret key establishment process.
At the cryptographic level, Clients in groups (and by extension
Members) are peers.  For instance, any Client can add a member to 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 authentication and
access control.  Thus, for instance, while it might be technically
possible for any member to send a message adding a new member to a
group, the group might have the policy that only certain members are
allowed to make changes and thus other members can ignore or reject
such a message from an unauthorized user.
In MLS a Group is defined as a set of Members who possibly use
multiple endpoint devices (Clients) to interact with the Messaging
Service.  These Clients will typically correspond to end-user devices
such as phones, web clients or other devices running MLS.
Each member device owns a long term identity key pair that uniquely
defines its identity to other Members of the Group.  Because a single
Member may operate multiple devices simultaneously (e.g., a desktop
and a phone) or sequentially (e.g., replacing one phone with
another), the formal definition of a Group in MLS is the set of
Clients that has legitimate knowledge of the shared (Encryption)
Group Key established in the group key establishment phase of the
protocol.
In some messaging systems, Clients belonging to the same Member must
all share the same identity key pair, but MLS does not assume this.
The MLS architecture considers the more general case and allows for
important use cases, such as a Member adding a new Client when all
their existing clients are offline.
The basic function of the Authentication Service is to provide a
trusted mapping from user identities (usernames, phone numbers,
etc.), which exist 1:1 with Members, to identity keys, which may
either be one per Client or may be shared amongst the Clients
attached to a Member.
A certification authority or similar service which signs some sort
of portable credential binding an identity to a key.
At the cryptographic level, clients in groups (and by extension
Members) are peers.  For instance, any client can add another client
to 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 authentication and
access control at the application layer.  Thus, for instance, while
it might be technically possible for any member to send a message
adding a new client to a group, the group might have the policy that
only certain members are allowed to make changes and thus other
members can ignore or reject such a message from an unauthorized
user.
Informally, a group is a set of users who possibly use multiple
endpoint devices to interact with the Messaging Service.  These
members will typically correspond to end-user devices such as phones,
web clients or other devices running MLS, which are called clients.
Each client owns at least one long term identity key pair that
uniquely defines its identity to other clients or members a the
Group.  Because a single user may operate multiple devices
simultaneously (e.g., a desktop and a phone) or sequentially (e.g.,
replacing one phone with another), the formal definition of a group
in MLS is the set of clients that has knowledge of the shared group
secret established in the group key establishment phase of the
protocol.  Multiple user devices can be grouped, appearing as one
virtual client to the rest of the group.
In some messaging systems, clients belonging to the same user must
all share the same identity key pair, but MLS does not assume this.
The MLS architecture considers the more general case and allows for
important use cases, such as a member adding a new client when all
their existing clients are offline.
To act as a directory service providing the keying material
(authentication keys and initial keying material) for Clients to
use.  This allows a Client to establish a shared key and send
encrypted messages to other Clients even if the other Client is
offline.
A credential from the Authentication service attesting to the
binding between the Member and the Client's identity key.
The member's initial keying material signed with the Client's
identity key.
As noted above, Members may have multiple Clients, each with their
own keying material, and thus there may be multiple entries stored by
each Member.
When a Client wishes to establish a group and send an initial message
to that group, it contacts the DS and retrieves the initial key
material for each other Member, verifies it using the identity key,
and then is able to form a joint key with each other Client, and from
those forms the group key, which it can use for the encryption of
messages.
To act as a directory service providing the initial keying
material for clients to use.  This allows a client to establish a
shared key and send encrypted messages to other clients even if
the other client is offline.
A credential from the Authentication service attesting to the
binding between the user and the client's identity key.
The client's initial keying material signed with the client's
identity key.
As noted above, users may own multiple clients, each with their own
keying material, and thus there may be multiple entries stored by
each user.
When a client wishes to establish a group and send an initial message
to that group, it contacts the DS and retrieves the initial key
material for each other client, verifies it using the identity key,
and from those forms the group secret, which it can use for the
encryption of messages.
Reliable delivery: when a message is provided to the DS, it is
eventually delivered to all group members.
In-order delivery: messages are delivered to the group in the
order they are received from a given Client and in approximately
the order in which they are sent by Clients.  The latter is an
approximate guarantee because multiple Clients may send messages
at the same time and so the DS needs some latitude in reordering
between Clients.
Consistent ordering: the DS must ensure that all Clients have the
same view of message ordering.
The MLS protocol itself can verify these properties.  For instance,
if the DS reorders messages from a Client or provides different
Clients with inconsistent orderings, then Clients can to detect this
misconduct.  However, MLS need not provide mechanisms to recover from
a misbehaving DS.
Note that some forms of DS misbehavior are still possible and
difficult to detect.  For instance, a DS can simply refuse to relay
messages to and from a given Client.  Without some sort of side
information, other Clients cannot generally distinguish this form of
Denial of Service (DoS) attack from the Client being actually
offline.
Reliable delivery: when a message is provided to the DS, it is
eventually delivered to all clients.
In-order delivery: messages are delivered to the group in the
order they are received from a given client and in approximately
the order in which they are sent by clients.  The latter is an
approximate guarantee because multiple clients may send messages
at the same time and so the DS needs some latitude in enforcing
ordering across clients.
Consistent ordering: the DS must ensure that all clients have the
same view of message ordering for cryptographically relevant
operations.  This means that the DS MUST enforce global
consistency of the ordering of these messages while MLS provides
causal consistency of the application messages for each sender.
The MLS protocol itself can verify these properties.  For instance,
if the DS reorders messages from a client or provides different
clients with inconsistent orderings, then clients can detect this
misconduct.  However, MLS need not provide mechanisms to recover from
a misbehaving DS.
Note that some forms of DS misbehavior are still possible and
difficult to detect.  For instance, a DS can simply refuse to relay
messages to and from a given client.  Without some sort of side
information, other clients cannot generally distinguish this form of
Denial of Service (DoS) attack.
MLS is designed as a large scale group messaging protocol and hence
aims to provide performance and safety to its users.  Messaging
systems that implement MLS provide support for conversations
involving two or more participants, and aim to scale to approximately
50,000 clients, typically including many Members using multiple
devices.
No operation in MLS requires two distinct users to be online
simultaneously.  In particular, clients participating in
conversations protected using MLS can update shared keys, add or
remove new members, and send messages and attachments without waiting
for another user's reply.
MLS is designed as a large scale group messaging protocol and hence
aims to provide performance and safety to its users.  Messaging
systems that implement MLS provide support for conversations
involving two or more members, and aim to scale to approximately
50,000 members, typically including many users using multiple
devices.
No operation in MLS requires two distinct users or clients to be
online simultaneously.  In particular, clients participating in
conversations protected using MLS can update shared keys, add or
remove new members, and send messages and attachments without waiting
for another user's reply.
It is typically expected for Members of the Group to own different
devices.
A new device can join the group and will be considered as a new
Client by the protocol.  This Client will not gain access to the
history even if it is owned by someone who is already a Member of the
Group.  Restoring history is typically not allowed at the protocol
level but applications can elect to provide such a mechanism outside
of MLS.
It is typically expected for users within Group to own different
devices.
A new device can be added to a group by sharing of an existing client
secrets or be considered as a new client by the protocol.  This
client will not gain access to the history even if it is owned by
someone who owns another member of the Group.  Restoring history is
typically not allowed at the protocol level but applications can
elect to provide such a mechanism outside of MLS.
The protocol aims to be compatible with federated environments.
While this document does not specify all necessary mechanisms
required for federation, multiple MLS implementations can
interoperate and to form federated systems if they use compatible
wire encodings.
The protocol aims to be compatible with federated environments.
While this document does not specify all necessary mechanisms
required for federation, multiple MLS implementations can
interoperate to form federated systems if they use compatible wire
encodings.
We assume that all transport connections are secured via some
transport layer security mechanism such as TLS I-D.ietf-tls-tls13.
However, as noted above, the security of MLS will generally survive
compromise of the transport layer, so long as identities provided by
the AS are authenticated at a minimum.
We assume that all transport connections are secured via some
transport layer security mechanism such as TLS I-D.ietf-tls-tls13.
However, as noted above, the security of MLS will generally survive
compromise of the transport layer, so long as identity keys provided
by the AS are authenticated at a minimum.
Message Integrity and Authentication mean that an honest Client can
only accept a message if it was sent by a group member and that one
Client cannot send a message which other Clients accept as being from
another Client.
A corollary to this statement is that the AS and the DS cannot read
the content of messages sent between Members as they are not Members
of the Group.  MLS optionally provides additional protections
regarding traffic analysis so as to reduce the ability of
adversaries, or a compromised member of the messaging system, to
deduce the content of the messages depending on (for example) their
size.  One of these protections includes padding messages in order to
produce ciphertexts of standard length.  While this protection is
highly recommended it is not mandatory as it can be costly in terms
of performance for clients and the MS.
Message Integrity and Authentication mean that an honest client can
only accept a message if it was sent by a group member and that a
client cannot send a message which other clients would accept as
being from a different client.
A corollary to this statement is that the AS and the DS cannot read
the content of messages sent between members as they are not members
of the group.  MLS optionally provides additional protections
regarding traffic analysis so as to reduce the ability of
adversaries, to deduce the content of the messages depending on (for
example) their size.  One of these protections includes padding
messages in order to produce ciphertexts of standard length.  While
this protection is highly recommended it is not mandatory as it can
be costly in terms of performance for clients and the MS.
FS means that access to all encrypted traffic history combined with
an access to all current keying material on clients will not defeat
the secrecy properties of messages older than the oldest key of the
client.  Note that this means that clients have the extremely
important role of deleting appropriate keys as soon as they have been
used with the expected message, otherwise the secrecy of the messages
and the security for MLS is considerably weakened.
PCS means that if a group member is compromised at some time t but
subsequently performs an update at some time t', then all MLS
guarantees apply to messages sent after time t'.  For example, if an
adversary learns all secrets known to Alice at time t, including both
Alice's secret keys and all shared group keys, but Alice performs a
key update at time t', then the adversary is unable to violate any of
the MLS security properties after time t'.
FS means that access to all encrypted traffic history combined with
an access to all current keying material on clients will not defeat
the secrecy properties of messages older than the oldest key of the
compromised client.  Note that this means that clients have the
extremely important role of deleting appropriate keys as soon as they
have been used with the expected message, otherwise the secrecy of
the messages and the security for MLS is considerably weakened.
PCS means that if a group member is compromised at some time T but
subsequently performs an update at some time T', then all MLS
guarantees apply to messages sent after time T'.  For example, if an
adversary learns all secrets known to Alice at time T, including both
Alice's secrets and all shared group secrets, but Alice performs a
key update at time T', which is not under the control of the
adversary, then the adversary is unable to violate any of the MLS
security properties after time T'.
Some applications may wish to enforce ACLs to limit addition or
removal of group members, to privileged users.  Others may wish to
require authorization from the current group members or a subset
thereof.  Regardless, MLS does not allow addition or removal of group
members without informing all other members.
Once a Member is part of a Group, the set of devices controlled by
the member can only be altered by an authorized member of the group.
This authorization could depend on the application: some applications
might want to allow certain other members of the group to add or
remove devices on behalf of another member, while other applications
might want a more strict policy and allow only the owner of the
devices to add or remove them at the potential cost of weaker PCS
guarantees.
Some applications may wish to enforce ACLs to limit addition or
removal of group members, to privileged clients or users.  Others may
wish to require authorization from the current group members or a
subset thereof.  Regardless, MLS does not allow addition or removal
of group members without informing all other members.
Once a client is part of a group, the set of devices controlled by
the user can only be altered by an authorized member of the group.
This authorization could depend on the application: some applications
might want to allow certain other members of the group to add or
remove devices on behalf of another member, while other applications
might want a more strict policy and allow only the owner of the
devices to add or remove them at the potential cost of weaker PCS
guarantees.
Members who are removed from a group do not enjoy special privileges:
compromise of a removed group member does not affect the security of
messages sent after their removal.
Members who are removed from a group do not enjoy special privileges:
compromise of a removed group member does not affect the security of
messages sent after their removal but might affect previous messages
if the group secrets have not been deleted properly.
In general, MLS only provides limited protection against compromised
Clients.  When the Client is compromised, then the attacker will
obviously be able to decrypt any messages for groups in which the
Client is a member.  It will also be able to send messages
impersonating the compromised Client until the Client updates its
keying material (see fs-and-pcs).  MLS attempts to provide some
security in the face of client compromise.
In addition, a Client cannot send a message to a group which appears
to be from another Client with a different identity.  Note that if
Clients from the same Member share keying material, then one will be
able to impersonate another.
In general, MLS only provides limited protection against compromised
clients.  When the client secrets are compromised, then the attacker
will obviously be able to decrypt any messages for groups in which
the client is a member.  It will also be able to send messages
impersonating the compromised client until the client updates its
keying material (see fs-and-pcs).  MLS attempts to provide some
security in the face of client compromise.
In addition, a client cannot send a message to a group which appears
to be from another client with a different identity.  Note that if
devices from the same user share keying material, then one will be
able to impersonate another.