Draft: draft-rescorla-mls-architecture

Commentary: Editing pass throughout .
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.
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.  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
just ignore such a message from an unauthorized user.
Each member device owns a long term identity key pair that uniquely
defines its identity to other Members of the Group.  As single end-
user may operate multiple devices simultaneously (e.g., a desktop and
a phone) or sequentially (e.g., replacing one phone with another),
hence 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
(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.
Each member device owns a long term identity key pair that uniquely
defines its identity to other Members of the Group.  As single end-
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 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.  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 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.
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 a malicious or
untrusted AS.
A credential from the Authentication service attesting to the the
binding between the Member and the Client's identity key.
A credential from the Authentication service attesting to the
binding between the Member and the Client's identity key.
To prevent that from happening, the MLS threat model considers the
case of a corrupted or untrusted DS that would leak all information
at its disposal.  Hence, in this Untrusted DS scenario, MLS will
enforce that the DS MUST NOT be aware these informations.  While not
providing the DS with this information might be enough in certain
scenarios, the strong threat model of MLS in this scenario provides
counter measures against potential traffic analysis that could be
done at the DS level.
To prevent that from happening, the MLS threat model threat-model
considers the case of a corrupted or untrusted DS that would leak all
information at its disposal.  Hence, in this Untrusted DS scenario,
MLS will enforce that the DS MUST NOT be aware these informations.
While not providing the DS with this information might be enough in
certain scenarios, the strong threat model of MLS in this scenario
provides counter measures against potential traffic analysis that
could be done at the DS level.
The policy regarding the time ellapsed before an offline member must
be removed from the group is not specified by this document as it may
vary depending on the security expectations from the Group.  Hence it
is left to the application layer to agree upon and signal this value
to the Delivery Service (DS).
The policy regarding the time elapsed before an offline member must
be removed from the group is not specified by this document as it may
vary depending on the security expectations from the Group.  Hence it
is left to the application layer to agree upon and signal this value
to the Delivery Service (DS).
MLS is intended to provide strong guarantees in the face of
compromise of the DS.  Even a totally compromised DS should not be
able to read messages or inject messages that will be acceptable to
legitimate Clients.  It should also not be able to undetectable
remove, reorder or replay messages.
MLS is intended to provide strong guarantees in the face of
compromise of the DS.  Even a totally compromised DS should not be
able to read messages or inject messages that will be acceptable to
legitimate Clients.  It should also not be able to undetectably
remove, reorder or replay messages.
Because the DS is responsible for providing initial keying material
to Clients, it can provide stale keys.  This doesn't inherently lead
to compromise of the message stream, but does allow it to attack
forward security to a limited extent.  This threat can be mitigated
by having initial keys expire.
A compromised AS is a more serious matter, as the AS can provide
incorrect or adversarial identities to clients.  As noted in
authentication-service, mitigating this form of attack requires some
sort of transparency/logging mechanism.  Absent such a mechanism, MLS
will only provide limited security against a compromised AS.
Because the DS is responsible for providing the initial keying
material to Clients, it can provide stale keys.  This doesn't
inherently lead to compromise of the message stream, but does allow
it to attack forward security to a limited extent.  This threat can
be mitigated by having initial keys expire.
A compromised AS is a serious matter, as the AS can provide incorrect
or adversarial identities to clients.  As noted in authentication-
service, mitigating this form of attack requires some sort of
transparency/logging mechanism.  Without such a mechanism, MLS will
only provide limited security against a compromised AS.
The protocol is designed in a way that limits the server-side (AS and
DS) metadata footprint.  The DS must only persist data required for
the delivery of messages and avoid Personally Identifiable
Information (PII) or other sensitive metadata wherever possible.  A
Messaging Service provider that has control over both the AS and the
DS, will not be able to correllate encrypted messages forwarded by
the DS, with the initial public keypairs signed by the AS.
The protocol is designed in a way that limits the server-side (AS and
DS) metadata footprint.  The DS must only persist data required for
the delivery of messages and avoid Personally Identifiable
Information (PII) or other sensitive metadata wherever possible.  A
Messaging Service provider that has control over both the AS and the
DS, will not be able to correlate encrypted messages forwarded by the
DS, with the initial public keypairs signed by the AS.
The security properties expected for attachments in the MLS protocol
are very similar to the ones expected from messages.  The distinction
between messages and attachments stems from the fact that the typical
average time between the download of a message and the one from the
attachements may be different.  For many reasons, the usual one being
the lack of high bandwith network connectivity, the lifetime of the
cryptographic keys for attachments is usually higher than for
messages, hence slightly weakening the PCS guarantees for
attachments.
The security properties expected for attachments in the MLS protocol
are very similar to the ones expected from messages.  The distinction
between messages and attachments stems from the fact that the typical
average time between the download of a message and the one from the
attachments may be different.  For many reasons, the usual one being
the lack of high bandwidth network connectivity, the lifetime of the
cryptographic keys for attachments is usually higher than for
messages, hence slightly weakening the PCS guarantees for
attachments.