< draft-ietf-mls-architecture-01.txt   draft-ietf-mls-architecture-02.txt >
Network Working Group E. Omara Network Working Group E. Omara
Internet-Draft Google Internet-Draft Google
Intended status: Informational B. Beurdouche Intended status: Informational B. Beurdouche
Expires: April 25, 2019 INRIA Expires: September 12, 2019 INRIA
E. Rescorla E. Rescorla
Mozilla Mozilla
S. Inguva S. Inguva
Twitter Twitter
A. Kwon A. Kwon
MIT MIT
A. Duric A. Duric
Wire Wire
October 22, 2018 March 11, 2019
The Messaging Layer Security (MLS) Architecture The Messaging Layer Security (MLS) Architecture
draft-ietf-mls-architecture-01 draft-ietf-mls-architecture-02
Abstract Abstract
This document describes the architecture and requirements for the This document describes the architecture and requirements for the
Messaging Layer Security (MLS) protocol. MLS provides a security Messaging Layer Security (MLS) protocol. MLS provides a security
layer for group messaging applications with from two to a large layer for group messaging applications with from two to a large
number of clients. It is meant to protect against eavesdropping, number of clients. It is meant to protect against eavesdropping,
tampering, and message forgery. tampering, and message forgery.
Status of This Memo Status of This Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Setting . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Setting . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Group, Members and Clients . . . . . . . . . . . . . . . 5 2.1. Group, Members and Clients . . . . . . . . . . . . . . . 5
2.2. Authentication Service . . . . . . . . . . . . . . . . . 6 2.2. Authentication Service . . . . . . . . . . . . . . . . . 6
2.3. Delivery Service . . . . . . . . . . . . . . . . . . . . 6 2.3. Delivery Service . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Key Storage . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. Key Storage . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Key Retrieval . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Key Retrieval . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Delivery of messages and attachments . . . . . . . . 7 2.3.3. Delivery of messages and attachments . . . . . . . . 8
2.3.4. Membership knowledge . . . . . . . . . . . . . . . . 8 2.3.4. Membership knowledge . . . . . . . . . . . . . . . . 8
2.3.5. Membership and offline members . . . . . . . . . . . 8 2.3.5. Membership and offline members . . . . . . . . . . . 9
3. System Requirements . . . . . . . . . . . . . . . . . . . . . 9 3. System Requirements . . . . . . . . . . . . . . . . . . . . . 9
3.1. Functional Requirements . . . . . . . . . . . . . . . . . 9 3.1. Functional Requirements . . . . . . . . . . . . . . . . . 9
3.1.1. Asynchronous Usage . . . . . . . . . . . . . . . . . 9 3.1.1. Asynchronous Usage . . . . . . . . . . . . . . . . . 9
3.1.2. Recovery After State Loss . . . . . . . . . . . . . . 9 3.1.2. Recovery After State Loss . . . . . . . . . . . . . . 9
3.1.3. Support for Multiple Devices . . . . . . . . . . . . 9 3.1.3. Support for Multiple Devices . . . . . . . . . . . . 9
3.1.4. Extensibility / Pluggability . . . . . . . . . . . . 9 3.1.4. Extensibility / Pluggability . . . . . . . . . . . . 10
3.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.6. Federation . . . . . . . . . . . . . . . . . . . . . 10 3.1.6. Federation . . . . . . . . . . . . . . . . . . . . . 10
3.1.7. Compatibility with future versions of MLS . . . . . . 10 3.1.7. Compatibility with future versions of MLS . . . . . . 10
3.2. Security Requirements . . . . . . . . . . . . . . . . . . 10 3.2. Security Requirements . . . . . . . . . . . . . . . . . . 10
3.2.1. Connections between Clients and Servers (one-to-one) 10 3.2.1. Connections between Clients and Servers (one-to-one) 11
3.2.2. Message Secrecy and Authentication . . . . . . . . . 10 3.2.2. Message Secrecy and Authentication . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Transport Security Links . . . . . . . . . . . . . . . . 13 4.1. Transport Security Links . . . . . . . . . . . . . . . . 13
4.2. Delivery Service Compromise . . . . . . . . . . . . . . . 13 4.2. Delivery Service Compromise . . . . . . . . . . . . . . . 14
4.3. Authentication Service Compromise . . . . . . . . . . . . 14 4.3. Authentication Service Compromise . . . . . . . . . . . . 14
4.4. Client Compromise . . . . . . . . . . . . . . . . . . . . 14 4.4. Client Compromise . . . . . . . . . . . . . . . . . . . . 14
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . 15 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 7. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH
The source for this draft is maintained in GitHub. Suggested changes The source for this draft is maintained in GitHub. Suggested changes
should be submitted as pull requests at https://github.com/mlswg/mls- should be submitted as pull requests at https://github.com/mlswg/mls-
architecture. Instructions are on that page as well. Editorial architecture. Instructions are on that page as well. Editorial
changes can be managed in GitHub, but any substantive change should changes can be managed in GitHub, but any substantive change should
be discussed on the MLS mailing list. be discussed on the MLS mailing list.
End-to-end security is a requirement for instant messaging systems End-to-end security is a requirement for instant messaging systems
and is commonly deployed in many such systems. In this context, and is commonly deployed in many such systems. In this context,
"end-to-end" captures the notion that users of the system enjoy some "end-to-end" captures the notion that users of the system enjoy some
level of security - with the precise level depending on the system level of security - with the precise level depending on the system
skipping to change at page 3, line 36 skipping to change at page 3, line 41
have some degree of interoperability at the message level, though have some degree of interoperability at the message level, though
they may have incompatible identity/authentication infrastructures. they may have incompatible identity/authentication infrastructures.
This document is intended to describe the overall messaging system This document is intended to describe the overall messaging system
architecture which the MLS protocol fits into, and the requirements architecture which the MLS protocol fits into, and the requirements
which it is intended to fulfill. which it is intended to fulfill.
2. General Setting 2. General Setting
A Group using a Messaging Service (MS) comprises a set of A Group using a Messaging Service (MS) comprises a set of
participants called Members where each Member is typically expected participants called Members where each member is typically expected
to own multiple devices, called Clients. A group may be as small as 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 two members (the simple case of person to person messaging) or as
large as thousands. In order to communicate securely, Group Members large as thousands. In order to communicate securely, clients
initially use services at their disposal to obtain the necessary initially use services at their disposal to obtain the necessary
secrets and credentials required for security. secrets and credentials required for security.
The Messaging Service (MS) presents as two abstract services that The Messaging Service (MS) presents as two abstract services that
allow Members to prepare for sending and receiving messages securely: allow clients to prepare for sending and receiving messages securely:
o An Authentication Service (AS) which is responsible for o An Authentication Service (AS) which is responsible for
maintaining user long term identities, issuing credentials which maintaining user long term identities, issuing credentials which
allow them to authenticate each other, and potentially allowing allow them to authenticate each other, and potentially allowing
users to discover each others long-term identity keys. users to discover each others long-term identity keys.
o A Delivery Service (DS) which is responsible for receiving and o A Delivery Service (DS) which is responsible for receiving and
redistributing messages between group members. In the case of redistributing messages between group members. In the case of
group messaging, the delivery service may also be responsible for group messaging, the delivery service may also be responsible for
acting as a "broadcaster" where the sender sends a single message acting as a "broadcaster" where the sender sends a single message
to a group which is then forwarded to each recipient in the group 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 by the DS. The DS is also responsible for storing and delivering
initial public key material required in order to proceed with the initial public key material required by clients in order to
group secret key establishment process. proceed with the group secret key establishment process.
---------------- -------------- ---------------- --------------
| Authentication | | Delivery | | Authentication | | Delivery |
| Service (AS) | | Service (DS) | | Service (AS) | | Service (DS) |
---------------- -------------- ---------------- --------------
/ | \ Group / | \ Group
********************************************************* *********************************************************
* / | \ * * / | \ *
* / | \ * * / | \ *
* ---------- ---------- ---------- * * ---------- ---------- ---------- *
* | Client 0 | | Client 1 | | Client N | * * | Client 0 | | Client 1 | | Client N | *
* ---------- ---------- ---------- * * ---------- ---------- ---------- *
* ............................ ........... * * ............................. ............ *
* Member 0 Member 1 * * User 0 User 1 *
* * * *
********************************************************* *********************************************************
In many systems, the AS and the DS are actually operated by the same In many systems, the AS and the DS are actually operated by the same
entity and may even be the same server. However, they are logically entity and may even be the same server. However, they are logically
distinct and, in other systems, may be operated by different distinct and, in other systems, may be operated by different
entities, hence we show them as being separate here. Other entities, hence we show them as being separate here. Other
partitions are also possible, such as having a separate directory partitions are also possible, such as having a separate directory
server. server.
skipping to change at page 5, line 14 skipping to change at page 5, line 16
the encrypted message(s) to the DS, which forwards them to the the encrypted message(s) to the DS, which forwards them to the
recipients. recipients.
4. Bob and/or Charlie respond to Alice's message. Their messages 4. Bob and/or Charlie respond to Alice's message. Their messages
might trigger a new key derivation step which allows the shared might trigger a new key derivation step which allows the shared
group key to be updated to provide post-compromise security group key to be updated to provide post-compromise security
Section 3.2.2.1. Section 3.2.2.1.
Clients may wish to do the following: Clients may wish to do the following:
o create a group by inviting a set of other members; o create a group by inviting a set of other clients;
o add one or more members to an existing group; o add one or more clients to an existing group;
o remove one or more members from an existing group; o remove one or more members from an existing group;
o join an existing group; o join an existing group;
o leave a group; o leave a group;
o send a message to everyone in the group; o send a message to everyone in the group;
o receive a message from someone in the group. o receive a message from someone in the group.
At the cryptographic level, Clients in groups (and by extension At the cryptographic level, clients in groups (and by extension
Members) are peers. For instance, any Client can add a member to a Members) are peers. For instance, any client can add another client
group. This is in contrast to some designs in which there is a 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 single group controller who can modify the group. MLS is compatible
with having group administration restricted to certain users, but we with having group administration restricted to certain users, but we
assume that those restrictions are enforced by authentication and assume that those restrictions are enforced by authentication and
access control. Thus, for instance, while it might be technically access control at the application layer. Thus, for instance, while
possible for any member to send a message adding a new member to a it might be technically possible for any member to send a message
group, the group might have the policy that only certain members are adding a new client to a group, the group might have the policy that
allowed to make changes and thus other members can ignore or reject only certain members are allowed to make changes and thus other
such a message from an unauthorized user. members can ignore or reject such a message from an unauthorized
user.
2.1. Group, Members and Clients 2.1. Group, Members and Clients
In MLS a Group is defined as a set of Members who possibly use Informally, a group is a set of users who possibly use multiple
multiple endpoint devices (Clients) to interact with the Messaging endpoint devices to interact with the Messaging Service. These
Service. These Clients will typically correspond to end-user devices members will typically correspond to end-user devices such as phones,
such as phones, web clients or other devices running MLS. web clients or other devices running MLS, which are called clients.
Each member device owns a long term identity key pair that uniquely Each client owns at least one long term identity key pair that
defines its identity to other Members of the Group. Because a single uniquely defines its identity to other clients or members a the
Member may operate multiple devices simultaneously (e.g., a desktop Group. Because a single user may operate multiple devices
and a phone) or sequentially (e.g., replacing one phone with simultaneously (e.g., a desktop and a phone) or sequentially (e.g.,
another), the formal definition of a Group in MLS is the set of replacing one phone with another), the formal definition of a group
Clients that has legitimate knowledge of the shared (Encryption) in MLS is the set of clients that has knowledge of the shared group
Group Key established in the group key establishment phase of the secret established in the group key establishment phase of the
protocol. 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 Member must In some messaging systems, clients belonging to the same user must
all share the same identity key pair, but MLS does not assume this. all share the same identity key pair, but MLS does not assume this.
The MLS architecture considers the more general case and allows for The MLS architecture considers the more general case and allows for
important use cases, such as a Member adding a new Client when all important use cases, such as a member adding a new client when all
their existing clients are offline. their existing clients are offline.
MLS has been designed to provide similar security guarantees to all MLS has been designed to provide similar security guarantees to all
Clients, for all group sizes, even when it reduces to only two clients, for all group sizes, even when it reduces to only two
Clients. clients.
2.2. Authentication Service 2.2. Authentication Service
The basic function of the Authentication Service is to provide a The basic function of the Authentication Service (AS) is to provide a
trusted mapping from user identities (usernames, phone numbers, trusted mapping from user identities (usernames, phone numbers,
etc.), which exist 1:1 with Members, to identity keys, which may etc.), to long-term identity keys, which may either be one per client
either be one per Client or may be shared amongst the Clients or may be shared amongst the clients attached to a user. It
attached to a Member. typically acts as:
o A certification authority or similar service which signs some sort o A certification authority, or similar service, which signs some
of portable credential binding an identity to a key. sort of portable credential binding an identity to a key;
o A directory server which provides the key for a given identity o A directory server which provides the key for a given identity
(presumably this connection is secured via some form of transport (presumably this connection is secured via some form of transport
security such as TLS). security such as TLS).
By definition, the AS is invested with a large amount of trust. A By definition, the AS is invested with a large amount of trust. A
malicious AS can impersonate - or allow an attacker to impersonate - malicious AS can impersonate - or allow an attacker to impersonate -
any user of the system. This risk can be mitigated by publishing the 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 binding between identities and keys in a public log such as Key
Transparency (KT) [KeyTransparency]. It is possible to build a Transparency (KT) [KeyTransparency]. It is possible to build a
functional MLS system without any kind of public key logging, but functional MLS system without any kind of public key logging, but
such a system will necessarily be somewhat vulnerable to attack by a such a system will necessarily be somewhat vulnerable to attack by a
malicious or untrusted AS. malicious or untrusted AS.
2.3. Delivery Service 2.3. Delivery Service
The Delivery Service (DS) is expected to play multiple roles in the The Delivery Service (DS) is expected to play multiple roles in the
Messaging Service architecture: Messaging Service architecture:
o To act as a directory service providing the keying material o To act as a directory service providing the initial keying
(authentication keys and initial keying material) for Clients to material for clients to use. This allows a client to establish a
use. This allows a Client to establish a shared key and send shared key and send encrypted messages to other clients even if
encrypted messages to other Clients even if the other Client is the other client is offline.
offline.
o To route messages between Clients and to act as a message o To route messages between clients and to act as a message
broadcaster, taking in one message and forwarding it to multiple broadcaster, taking in one message and forwarding it to multiple
Clients (also known as "server side fanout"). clients (also known as "server side fanout").
Depending on the level of trust given by the Group to the Delivery Depending on the level of trust given by the group to the Delivery
Service, the functional and security guarantees provided by MLS may Service, the functional and security guarantees provided by MLS may
differ. differ.
2.3.1. Key Storage 2.3.1. Key Storage
Upon joining the system, each Client stores its initial cryptographic Upon joining the system, each client stores its initial cryptographic
key material with the DS. This key material represents the initial key material with the DS. This key material represents the initial
contribution from each member that will be used in the establishment contribution that will be used in the establishment of the shared
of the shared group key. This initial keying material is group secret. This initial keying material is authenticated using
authenticated using the Client's identity key. Thus, the Client the client's identity key. Thus, the client stores:
stores:
o A credential from the Authentication service attesting to the o A credential from the Authentication service attesting to the
binding between the Member and the Client's identity key. binding between the user and the client's identity key.
o The member's initial keying material signed with the Client's o The client's initial keying material signed with the client's
identity key. identity key.
As noted above, Members may have multiple Clients, each with their As noted above, users may own multiple clients, each with their own
own keying material, and thus there may be multiple entries stored by keying material, and thus there may be multiple entries stored by
each Member. each user.
The Delivery Service is also responsible for allowing users to add,
remove or update their initial keying material and to ensure that the
identifier for these keys are unique accross all keys stored on the
DS.
2.3.2. Key Retrieval 2.3.2. Key Retrieval
When a Client wishes to establish a group and send an initial message 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 to that group, it contacts the DS and retrieves the initial key
material for each other Member, verifies it using the identity key, material for each other client, verifies it using the identity key,
and then is able to form a joint key with each other Client, and from and from those forms the group secret, which it can use for the
those forms the group key, which it can use for the encryption of encryption of messages.
messages.
2.3.3. Delivery of messages and attachments 2.3.3. Delivery of messages and attachments
The DS's main responsibility is to ensure delivery of messages. The DS's main responsibility is to ensure delivery of messages.
Specifically, we assume that DSs provide: Specifically, we assume that DSs provide:
o Reliable delivery: when a message is provided to the DS, it is o Reliable delivery: when a message is provided to the DS, it is
eventually delivered to all group members. eventually delivered to all clients.
o In-order delivery: messages are delivered to the group in the o In-order delivery: messages are delivered to the group in the
order they are received from a given Client and in approximately order they are received from a given client and in approximately
the order in which they are sent by Clients. The latter is an the order in which they are sent by clients. The latter is an
approximate guarantee because multiple Clients may send messages approximate guarantee because multiple clients may send messages
at the same time and so the DS needs some latitude in reordering at the same time and so the DS needs some latitude in enforcing
between Clients. ordering across clients.
o Consistent ordering: the DS must ensure that all Clients have the o Consistent ordering: the DS must ensure that all clients have the
same view of message ordering. 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.
Note that the DS may provide ordering guarantees by ensuring in-order Note that the DS may provide ordering guarantees by ensuring in-order
delivery or by providing messages with some kind of sequence delivery or by providing messages with some kind of sequence
information and allowing clients to reorder on receipt. information and allowing clients to reorder on receipt.
The MLS protocol itself can verify these properties. For instance, The MLS protocol itself can verify these properties. For instance,
if the DS reorders messages from a Client or provides different if the DS reorders messages from a client or provides different
Clients with inconsistent orderings, then Clients can to detect this clients with inconsistent orderings, then clients can detect this
misconduct. However, MLS need not provide mechanisms to recover from misconduct. However, MLS need not provide mechanisms to recover from
a misbehaving DS. a misbehaving DS.
Note that some forms of DS misbehavior are still possible and Note that some forms of DS misbehavior are still possible and
difficult to detect. For instance, a DS can simply refuse to relay difficult to detect. For instance, a DS can simply refuse to relay
messages to and from a given Client. Without some sort of side messages to and from a given client. Without some sort of side
information, other Clients cannot generally distinguish this form of information, other clients cannot generally distinguish this form of
Denial of Service (DoS) attack from the Client being actually Denial of Service (DoS) attack.
offline.
2.3.4. Membership knowledge 2.3.4. Membership knowledge
Group membership is itself sensitive information and MLS is designed Group membership is itself sensitive information and MLS is designed
so that neither the DS nor the AS need have static knowledge of which so that neither the DS nor the AS need have static knowledge of which
Clients are in which Group. However, they may learn this information clients are in which group. However, they may learn this information
through traffic analysis. For instance, in a server side fanout through traffic analysis. For instance, in a server side fanout
model, the DS learns that a given Client is sending the same message model, the DS learns that a given client is sending the same message
to a set of other Clients. In addition, there may be applications of to a set of other clients. In addition, there may be applications of
MLS in which the Group membership list is stored on some server MLS in which the group membership list is stored on some server
associated with the MS. associated with the MS.
2.3.5. Membership and offline members 2.3.5. Membership and offline members
Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely Because Forward Secrecy (FS) and Post-Compromise Security (PCS) rely
on the deletion and replacement of keying material, any Client which on the deletion and replacement of keying material, any client which
is persistently offline may still be holding old keying material and is persistently offline may still be holding old keying material and
thus be a threat to both FS and PCS if it is later compromised. MLS thus be a threat to both FS and PCS if it is later compromised. MLS
does not inherently defend against this problem, but MLS-using does not inherently defend against this problem, but MLS-using
systems can enforce some mechanism for doing so. Typically this will systems can enforce some mechanism for doing so. Typically this will
consist of evicting Clients which are idle for too long, thus consist of evicting clients which are idle for too long, thus
containing the threat of compromise. The precise details of such containing the threat of compromise. The precise details of such
mechanisms are a matter of local policy and beyond the scope of this mechanisms are a matter of local policy and beyond the scope of this
document. document.
3. System Requirements 3. System Requirements
3.1. Functional Requirements 3.1. Functional Requirements
MLS is designed as a large scale group messaging protocol and hence MLS is designed as a large scale group messaging protocol and hence
aims to provide performance and safety to its users. Messaging aims to provide performance and safety to its users. Messaging
systems that implement MLS provide support for conversations systems that implement MLS provide support for conversations
involving two or more participants, and aim to scale to approximately involving two or more members, and aim to scale to approximately
50,000 clients, typically including many Members using multiple 50,000 members, typically including many users using multiple
devices. devices.
3.1.1. Asynchronous Usage 3.1.1. Asynchronous Usage
No operation in MLS requires two distinct users to be online No operation in MLS requires two distinct users or clients to be
simultaneously. In particular, clients participating in online simultaneously. In particular, clients participating in
conversations protected using MLS can update shared keys, add or conversations protected using MLS can update shared keys, add or
remove new members, and send messages and attachments without waiting remove new members, and send messages and attachments without waiting
for another user's reply. for another user's reply.
Messaging systems that implement MLS provide a transport layer for Messaging systems that implement MLS provide a transport layer for
delivering messages asynchronously and reliably. delivering messages asynchronously and reliably.
3.1.2. Recovery After State Loss 3.1.2. Recovery After State Loss
Conversation participants whose local MLS state is lost or corrupted Conversation participants whose local MLS state is lost or corrupted
can reinitialize their state and continue participating in the can reinitialize their state and continue participating in the
conversation. This may entail some level of message loss, but does conversation. This may entail some level of message loss, but does
not result in permanent exclusion from the group. not result in permanent exclusion from the group.
3.1.3. Support for Multiple Devices 3.1.3. Support for Multiple Devices
It is typically expected for Members of the Group to own different It is typically expected for users within Group to own different
devices. devices.
A new device can join the group and will be considered as a new A new device can be added to a group by sharing of an existing client
Client by the protocol. This Client will not gain access to the secrets or be considered as a new client by the protocol. This
history even if it is owned by someone who is already a Member of the client will not gain access to the history even if it is owned by
Group. Restoring history is typically not allowed at the protocol someone who owns another member of the Group. Restoring history is
level but applications can elect to provide such a mechanism outside typically not allowed at the protocol level but applications can
of MLS. elect to provide such a mechanism outside of MLS.
3.1.4. Extensibility / Pluggability 3.1.4. Extensibility / Pluggability
Messages that do not affect the group state can carry an arbitrary Messages that do not affect the group state can carry an arbitrary
payload with the purpose of sharing that payload between group payload with the purpose of sharing that payload between group
members. No assumptions are made about the format of the payload. members. No assumptions are made about the format of the payload.
3.1.5. Privacy 3.1.5. Privacy
The protocol is designed in a way that limits the server-side (AS and The protocol is designed in a way that limits the server-side (AS and
skipping to change at page 10, line 20 skipping to change at page 10, line 33
(PII) or other sensitive metadata wherever possible. A Messaging (PII) or other sensitive metadata wherever possible. A Messaging
Service provider that has control over both the AS and the DS, will 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 not be able to correlate encrypted messages forwarded by the DS, with
the initial public keys signed by the AS. the initial public keys signed by the AS.
3.1.6. Federation 3.1.6. Federation
The protocol aims to be compatible with federated environments. The protocol aims to be compatible with federated environments.
While this document does not specify all necessary mechanisms While this document does not specify all necessary mechanisms
required for federation, multiple MLS implementations can required for federation, multiple MLS implementations can
interoperate and to form federated systems if they use compatible interoperate to form federated systems if they use compatible wire
wire encodings. encodings.
3.1.7. Compatibility with future versions of MLS 3.1.7. Compatibility with future versions of MLS
It is important that multiple versions of MLS be able to coexist in It is important that multiple versions of MLS be able to coexist in
the future. Thus, MLS offers a version negotiation mechanism; this the future. Thus, MLS offers a version negotiation mechanism; this
mechanism prevents version downgrade attacks where an attacker would mechanism prevents version downgrade attacks where an attacker would
actively rewrite messages messages with a lower protocol version than actively rewrite messages messages with a lower protocol version than
the ones originally offered by the endpoints. When multiple versions the ones originally offered by the endpoints. When multiple versions
of MLS are available, the negotiation protocol guarantees that the of MLS are available, the negotiation protocol guarantees that the
version agreed upon will be the highest version supported in common version agreed upon will be the highest version supported in common
skipping to change at page 10, line 35 skipping to change at page 11, line 4
It is important that multiple versions of MLS be able to coexist in It is important that multiple versions of MLS be able to coexist in
the future. Thus, MLS offers a version negotiation mechanism; this the future. Thus, MLS offers a version negotiation mechanism; this
mechanism prevents version downgrade attacks where an attacker would mechanism prevents version downgrade attacks where an attacker would
actively rewrite messages messages with a lower protocol version than actively rewrite messages messages with a lower protocol version than
the ones originally offered by the endpoints. When multiple versions the ones originally offered by the endpoints. When multiple versions
of MLS are available, the negotiation protocol guarantees that the of MLS are available, the negotiation protocol guarantees that the
version agreed upon will be the highest version supported in common version agreed upon will be the highest version supported in common
by the group. by the group.
3.2. Security Requirements 3.2. Security Requirements
3.2.1. Connections between Clients and Servers (one-to-one) 3.2.1. Connections between Clients and Servers (one-to-one)
We assume that all transport connections are secured via some We assume that all transport connections are secured via some
transport layer security mechanism such as TLS [I-D.ietf-tls-tls13]. transport layer security mechanism such as TLS [I-D.ietf-tls-tls13].
However, as noted above, the security of MLS will generally survive However, as noted above, the security of MLS will generally survive
compromise of the transport layer, so long as identities provided by compromise of the transport layer, so long as identity keys provided
the AS are authenticated at a minimum. by the AS are authenticated at a minimum.
3.2.2. Message Secrecy and Authentication 3.2.2. Message Secrecy and Authentication
The trust establishment step of the MLS protocol is followed by a The trust establishment step of the MLS protocol is followed by a
conversation protection step where encryption is used by clients to conversation protection step where encryption is used by clients to
transmit authenticated messages to other clients through the DS. transmit authenticated messages to other clients through the DS.
This ensures that the DS does not have access to the Group's private This ensures that the DS does not have access to the group's private
content. content.
MLS aims to provide Secrecy, Integrity and Authentication for all MLS aims to provide secrecy, integrity and authentication for all
messages. messages.
Message Secrecy in the context of MLS means that only intended Message Secrecy in the context of MLS means that only intended
recipients (current group members), can read any message sent to the recipients (current group members), can read any message sent to the
group, even in the context of an active adversary as described in the group, even in the context of an active adversary as described in the
threat model. threat model.
Message Integrity and Authentication mean that an honest Client can 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 only accept a message if it was sent by a group member and that a
Client cannot send a message which other Clients accept as being from client cannot send a message which other clients would accept as
another Client. being from a different client.
A corollary to this statement is that the AS and the DS cannot read 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 the content of messages sent between members as they are not members
of the Group. MLS optionally provides additional protections of the group. MLS optionally provides additional protections
regarding traffic analysis so as to reduce the ability of regarding traffic analysis so as to reduce the ability of
adversaries, or a compromised member of the messaging system, to adversaries, to deduce the content of the messages depending on (for
deduce the content of the messages depending on (for example) their example) their size. One of these protections includes padding
size. One of these protections includes padding messages in order to messages in order to produce ciphertexts of standard length. While
produce ciphertexts of standard length. While this protection is this protection is highly recommended it is not mandatory as it can
highly recommended it is not mandatory as it can be costly in terms be costly in terms of performance for clients and the MS.
of performance for clients and the MS.
Message content can be deniable if the signature keys are exchanged Message content can be deniable if the signature keys are exchanged
over a deniable channel prior to signing messages. over a deniable channel prior to signing messages.
3.2.2.1. Forward and Post-Compromise Security 3.2.2.1. Forward and Post-Compromise Security
MLS provides additional protection regarding secrecy of past messages MLS provides additional protection regarding secrecy of past messages
and future messages. These cryptographic security properties are and future messages. These cryptographic security properties are
Forward Secrecy (FS) and Post-Compromise Security (PCS). Forward Secrecy (FS) and Post-Compromise Security (PCS).
FS means that access to all encrypted traffic history combined with FS means that access to all encrypted traffic history combined with
an access to all current keying material on clients will not defeat an access to all current keying material on clients will not defeat
the secrecy properties of messages older than the oldest key of the the secrecy properties of messages older than the oldest key of the
client. Note that this means that clients have the extremely compromised client. Note that this means that clients have the
important role of deleting appropriate keys as soon as they have been extremely important role of deleting appropriate keys as soon as they
used with the expected message, otherwise the secrecy of the messages have been used with the expected message, otherwise the secrecy of
and the security for MLS is considerably weakened. the messages and the security for MLS is considerably weakened.
PCS means that if a group member is compromised at some time t but 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 subsequently performs an update at some time T', then all MLS
guarantees apply to messages sent after time t'. For example, if an guarantees apply to messages sent after time T'. For example, if an
adversary learns all secrets known to Alice at time t, including both 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 Alice's secrets and all shared group secrets, but Alice performs a
key update at time t', then the adversary is unable to violate any of key update at time T', which is not under the control of the
the MLS security properties after time t'. adversary, then the adversary is unable to violate any of the MLS
security properties after time T'.
Both of these properties are satisfied even against compromised DSs Both of these properties are satisfied even against compromised DSs
and ASs. and ASs.
3.2.2.2. Membership Changes 3.2.2.2. Membership Changes
MLS aims to provide agreement on group membership, meaning that all MLS aims to provide agreement on group membership, meaning that all
group members have agreed on the list of current group members. group members have agreed on the list of current group members.
Some applications may wish to enforce ACLs to limit addition or Some applications may wish to enforce ACLs to limit addition or
removal of group members, to privileged users. Others may wish to removal of group members, to privileged clients or users. Others may
require authorization from the current group members or a subset wish to require authorization from the current group members or a
thereof. Regardless, MLS does not allow addition or removal of group subset thereof. Regardless, MLS does not allow addition or removal
members without informing all other members. of group members without informing all other members.
Once a Member is part of a Group, the set of devices controlled by Once a client is part of a group, the set of devices controlled by
the member can only be altered by an authorized member of the group. the user can only be altered by an authorized member of the group.
This authorization could depend on the application: some applications This authorization could depend on the application: some applications
might want to allow certain other members of the group to add or might want to allow certain other members of the group to add or
remove devices on behalf of another member, while other applications remove devices on behalf of another member, while other applications
might want a more strict policy and allow only the owner of the 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 devices to add or remove them at the potential cost of weaker PCS
guarantees. guarantees.
Members who are removed from a group do not enjoy special privileges: Members who are removed from a group do not enjoy special privileges:
compromise of a removed group member does not affect the security of compromise of a removed group member does not affect the security of
messages sent after their removal. messages sent after their removal but might affect previous messages
if the group secrets have not been deleted properly.
3.2.2.3. Security of Attachments 3.2.2.3. Security of Attachments
The security properties expected for attachments in the MLS protocol The security properties expected for attachments in the MLS protocol
are very similar to the ones expected from messages. The distinction are very similar to the ones expected from messages. The distinction
between messages and attachments stems from the fact that the typical between messages and attachments stems from the fact that the typical
average time between the download of a message and the one from the average time between the download of a message and the one from the
attachments may be different. For many reasons (a typical reason attachments may be different. For many reasons (a typical reason
being the lack of high bandwidth network connectivity), the lifetime being the lack of high bandwidth network connectivity), the lifetime
of the cryptographic keys for attachments is usually higher than for of the cryptographic keys for attachments is usually higher than for
messages, hence slightly weakening the PCS guarantees for messages, hence slightly weakening the PCS guarantees for
attachments. attachments.
3.2.2.4. Denial of Service 3.2.2.4. Denial of Service
In general we do not consider Denial of Service (DoS) resistance to In general we do not consider Denial of Service (DoS) resistance to
be the responsibility of the protocol. However, it should not be be the responsibility of the protocol. However, it should not be
possible for anyone aside from the DS to perform a trivial DoS attack possible for anyone aside from the DS to perform a trivial DoS attack
from which it is hard to recover. from which it is hard to recover.
3.2.2.5. Non-Repudiation and Deniability 3.2.2.5. Non-Repudiation vs Deniability
As described in Section 4.4, MLS provides data origin authentication As described in Section 4.4, MLS provides strong authentication
within a group, such that one group member cannot send a message that within a group, such that a group member cannot send a message that
appears to be from another group member. Additionally, some services appears to be from another group member. Additionally, some services
require that a recipient be able to prove to the messaging service require that a recipient be able to prove to the messaging service
that a message was sent by a given Client, in order to report abuse. that a message was sent by a given client, in order to report abuse.
MLS supports both of these use cases. In some deployments, these MLS supports both of these use cases. In some deployments, these
services are provided by mechanisms which allow the receiver to prove services are provided by mechanisms which allow the receiver to prove
a message's origin to a third party (this if often called "non- a message's origin to a third party (this if often called "non-
repudiation"), but it should also be possible to operate MLS in a repudiation"), but it should also be possible to operate MLS in a
"deniable" mode where such proof is not possible. [[OPEN ISSUE: "deniable" mode where such proof is not possible. [[OPEN ISSUE:
Exactly how to supply this is still a protocol question.]] Exactly how to supply this is still a protocol question.]]
4. Security Considerations 4. Security Considerations
MLS adopts the Internet threat model [RFC3552] and therefore assumes MLS adopts the Internet threat model [RFC3552] and therefore assumes
that the attacker has complete control of the network. It is that the attacker has complete control of the network. It is
intended to provide the security services described in in the face of intended to provide the security services described in in the face of
such attackers. In addition, these guarantees are intended to such attackers. In addition, these guarantees are intended to
degrade gracefully in the presence of compromise of the transport degrade gracefully in the presence of compromise of the transport
security links as well as of both Clients and elements of the security links as well as of both clients and elements of the
messaging system, as described in the remainder of this section. messaging system, as described in the remainder of this section.
4.1. Transport Security Links 4.1. Transport Security Links
[TODO: Mostly DoS, message suppression, and leakage of group [TODO: Mostly DoS, message suppression, and leakage of group
membership.] membership.]
4.2. Delivery Service Compromise 4.2. Delivery Service Compromise
MLS is intended to provide strong guarantees in the face of MLS is intended to provide strong guarantees in the face of
compromise of the DS. Even a totally compromised DS should not be compromise of the DS. Even a totally compromised DS should not be
able to read messages or inject messages that will be acceptable to able to read messages or inject messages that will be acceptable to
legitimate Clients. It should also not be able to undetectably legitimate clients. It should also not be able to undetectably
remove, reorder or replay messages. remove, reorder or replay messages.
However, a DS can mount a variety of DoS attacks on the system, However, a DS can mount a variety of DoS attacks on the system,
including total DoS attacks (where it simply refuses to forward any including total DoS attacks (where it simply refuses to forward any
messages) and partial DoS attacks (where it refuses to forward messages) and partial DoS attacks (where it refuses to forward
messages to and from specific Clients). As noted in Section 2.3.3, messages to and from specific clients). As noted in Section 2.3.3,
these attacks are only partially detectable by clients without an these attacks are only partially detectable by clients without an
out-of-band channel. Ultimately, failure of the DS to provide out-of-band channel. Ultimately, failure of the DS to provide
reasonable service must be dealt with as a customer service matter, reasonable service must be dealt with as a customer service matter,
not via technology. not via technology.
Because the DS is responsible for providing the initial keying Because the DS is responsible for providing the initial keying
material to Clients, it can provide stale keys. This does not material to clients, it can provide stale keys. This does not
inherently lead to compromise of the message stream, but does allow inherently lead to compromise of the message stream, but does allow
it to attack forward security to a limited extent. This threat can it to attack forward security to a limited extent. This threat can
be mitigated by having initial keys expire. be mitigated by having initial keys expire.
4.3. Authentication Service Compromise 4.3. Authentication Service Compromise
A compromised AS is a serious matter, as the AS can provide incorrect A compromised AS is a serious matter, as the AS can provide incorrect
or adversarial identities to clients. As noted in Section 2.2, or adversarial identities to clients. As noted in Section 2.2,
mitigating this form of attack requires some sort of transparency/ mitigating this form of attack requires some sort of transparency/
logging mechanism. Without such a mechanism, MLS will only provide logging mechanism. Without such a mechanism, MLS will only provide
limited security against a compromised AS. limited security against a compromised AS.
4.4. Client Compromise 4.4. Client Compromise
In general, MLS only provides limited protection against compromised In general, MLS only provides limited protection against compromised
Clients. When the Client is compromised, then the attacker will clients. When the client secrets are compromised, then the attacker
obviously be able to decrypt any messages for groups in which the will obviously be able to decrypt any messages for groups in which
Client is a member. It will also be able to send messages the client is a member. It will also be able to send messages
impersonating the compromised Client until the Client updates its impersonating the compromised client until the client updates its
keying material (see Section 3.2.2.1). MLS attempts to provide some keying material (see Section 3.2.2.1). MLS attempts to provide some
security in the face of client compromise. security in the face of client compromise.
In addition, a Client cannot send a message to a group which appears 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 to be from another client with a different identity. Note that if
Clients from the same Member share keying material, then one will be devices from the same user share keying material, then one will be
able to impersonate another. able to impersonate another.
Finally, Clients should not be able to perform DoS attacks Finally, clients should not be able to perform DoS attacks
Section 3.2.2.4. Section 3.2.2.4.
5. Contributors 5. IANA Considerations
This document makes no requests of IANA.
6. Contributors
o Katriel Cohn-Gordon o Katriel Cohn-Gordon
University of Oxford University of Oxford
me@katriel.co.uk me@katriel.co.uk
o Cas Cremers o Cas Cremers
University of Oxford University of Oxford
cas.cremers@cs.ox.ac.uk cas.cremers@cs.ox.ac.uk
o Thyla van der Merwe o Thyla van der Merwe
skipping to change at page 15, line 9 skipping to change at page 15, line 31
thyla.van.der@merwe.tech thyla.van.der@merwe.tech
o Jon Millican o Jon Millican
Facebook Facebook
jmillican@fb.com jmillican@fb.com
o Raphael Robert o Raphael Robert
Wire Wire
raphael@wire.com raphael@wire.com
6. Informative References 7. Informative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[KeyTransparency] [KeyTransparency]
Google, ., "Key Transparency", n.d., Google, ., "Key Transparency", n.d.,
<https://KeyTransparency.org>. <https://KeyTransparency.org>.
 End of changes. 79 change blocks. 
163 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/