Draft: draft-rescorla-mls-architecture

Commentary: An edit pass - minor changes for readability .
This document is intended to describe the overall messaging system
architecture which the MLS protocol fits into and the requirements
which it is intended to fulfill.
This document is intended to describe the overall messaging system
architecture which the MLS protocol fits into, and the requirements
which it is intended to fulfill.
An Authentication Service (AS) which is responsible for
maintaining user long term identities, issuing credentials which
allow them to authenticate to each other, and potentially allowing
users to discover each others long-term identity keys.
An Authentication Service (AS) which is responsible for
maintaining user long term identities, issuing credentials which
allow them to authenticate each other, and potentially allowing
users to discover each others long-term identity keys.
At the cryptographic level, Clients in groups (and by extension
Members) are peers.  For instance, any Client should be able to add a
member to a group.  This is in contrast so some designs in which
there is a single group controller who can modify the group.  This is
still 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 were allowed to make changes and thus other members
would just ignore such a message from an unauthorized user.
At the cryptographic level, Clients in groups (and by extension
Members) are peers.  For instance, any Client should be able to add a
member to a group.  This is in contrast so some designs in which
there is a single group controller who can modify the group.  This is
still 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
just ignore such a message from an unauthorized user.
In some messaging systems, Clients belonging to the same member must
all share the same identity key pair, but MLS does not assume this
(this is 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).  For systems that allow multiple identity key pairs per
Member, some mechanism is required to detect the addition of new,
bogus Clients.  Key Transparency [TODO:REF] is one such potential
mechanisms, but others are also possible.
In some messaging systems, Clients belonging to the same member must
all share the same identity key pair, but MLS does not assume this
(this is 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).  For systems that allow multiple identity key pairs per
Member, some mechanism is required to detect the addition of new,
bogus Clients.  Key Transparency [TODO:REF] is one such potential
mechanism, but others are also possible.
By definition, the AS is invested in a large amount of trust.  A
malicious AS can impersonate - or allow an attacker to impersonate -
any user of the system.  This risk can be mitigated by publishing the
binding between identities and keys in a public log such as Key
Transparency (KT) [REF].  It is possible to build a functional MLS
system without any kind of public key logging, but such a system will
necessarily be somewhat vulnerable to attack by the AS.
By definition, the AS is invested with a large amount of trust.  A
malicious AS can impersonate - or allow an attacker to impersonate -
any user of the system.  This risk can be mitigated by publishing the
binding between identities and keys in a public log such as Key
Transparency (KT) [REF].  It is possible to build a functional MLS
system without any kind of public key logging, but such a system will
necessarily be somewhat vulnerable to attack by the AS.
Act as a directory service providing the keying material
(authentication keys and initial keying material) to sending
Clients.  This allows a Client to establish a shared key and send
encrypted messages to other Clients even if the other Client is
offline.
Route messages between Clients.
To act as a directory service providing the keying material
(authentication keys and initial keying material) to sending
Clients.  This allows a Client to establish a shared key and send
encrypted messages to other Clients even if the other Client is
offline.
To route messages between Clients.
When a Client wishes to establish a group and send an initial message
to that group, it contacts the DS and retrieves the initial keying
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 to encrypt messages.
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.
In-order delivery - messages are delivered to the group in the
order they are received from a given Client and in approximately
the order which they are sent by Clients.  This latter an
approximate guarantee because multiple Clients may send messages
at the same time and so the DS needs some latitude to reorder
between 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 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.
The MLS protocol itself should be able to verify these properties.
E.g., if the DS reorders messages from a Client or provides different
Clients with inconsistent orderings, then Clients should be able to
detect this misbehavior.  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 distinguishable this form
of Denial of Service attack from the Client being actually offline.
The MLS protocol itself should be able to verify these properties.
For instance, if the DS reorders messages from a Client or provides
different Clients with inconsistent orderings, then Clients should be
able 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.