Draft: draft-ietf-mls-architecture

Commentary: Address IESG comments from   and   ( SEC ) Also address IESG telechat comments from   ( INT ) because they overlap substantially Partially addresses (   ) - all DISCUSS issues except one already addressed in PR ( merged ) addresses some comments from ( Éric Vyncke ) - DISCUSS issues both addressed Completely addresses (   ) Addresses DISCUSS in ( Zaheduzzaman Sarker ) 
 This is not entirely correct . For instance , modern browsers increasingly use centrally distributed revocation information , and so this does not require network traffic to check revocation .
End-to-end security is a requirement for instant messaging systems
and is commonly deployed in many such systems.  In this context,
"end-to-end" captures the notion that users of the system enjoy some
level of security - with the precise level depending on the system
design - even in the face of malicious actions by the operator of the
messaging system.
End-to-end security is a used in the vast majority of instant
messaging systems, and also deployed in systems for other purposes
such as calling and conferencing.  In this context, "end-to-end"
captures the notion that users of the system enjoy some level of
security - with the precise level depending on the system design -
even in the face of malicious actions by the operator of the
messaging system.
Messaging Layer Security (MLS) specifies an architecture (this
document) and a protocol I-D.ietf-mls-protocol for providing end-to-
end security in this setting.  MLS is not intended as a full instant
messaging protocol but rather is intended to be embedded in concrete
protocols, such as XMPP RFC6120.  Implementations of the MLS protocol
will interoperate at the cryptographic level, though they may have
incompatibilities in terms of how protected messages are delivered,
contents of protected messages, and identity/authentication
infrastructures.  The MLS protocol has been designed to provide the
same security guarantees to all users, for all group sizes, even when
it reduces to only two users.
Messaging Layer Security (MLS) specifies an architecture (this
document) and a protocol I-D.ietf-mls-protocol for providing end-to-
end security in this setting.  MLS is not intended as a full instant
messaging protocol but rather is intended to be embedded in concrete
protocols, such as XMPP RFC6120.  Implementations of the MLS protocol
will interoperate at the cryptographic level, though they may have
incompatibilities in terms of how protected messages are delivered,
contents of protected messages, and identity/authentication
infrastructures.  The MLS protocol has been designed to provide the
same security guarantees to all users, for all group sizes, even for
a group of only two clients.
MLS provides a way for _clients_ to form _groups_ within which they
can communicate securely.  For example, a set of users might use
clients on their phones or laptops to join a group and communicate
with each other.  A group may be as small as two clients (e.g., for
simple person to person messaging) or as large as thousands.  A
client that is part of a group is a _member_ of that group.
MLS provides a way for _clients_ to form _groups_ within which they
can communicate securely.  For example, a set of users might use
clients on their phones or laptops to join a group and communicate
with each other.  A group may be as small as two clients (e.g., for
simple person to person messaging) or as large as tens of thousands.
A client that is part of a group is a _member_ of that group.
In an MLS group using a PKI for authentication, the AS would
comprise the certificate issuance and validation processes, both
of which involve logic inside MLS clients as well as various
servers.
In an MLS group using a Public Key Infrastructure (PKI) for
authentication, the AS would comprise the certificate issuance and
validation processes, both of which involve logic inside MLS
clients as well as various existing PKI roles (ex: Certification
Authorities).
Alice, Bob and Charlie create accounts with a service provider and
obtain credentials from the AS.
Alice, Bob, and Charlie create accounts with a service provider
and obtain credentials from the AS.
Several current messaging applications rely on users verifying
each others' key fingerprints for authentication.  In this
scenario, the issuance function is simply the generation of a key
pair (i.e., a credential is just an identifier and public key,
with no information to assist in verification).  The verification
function is the application functionality that enables users to
verify keys.
In a system based on Key Transparency (KT) KeyTransparency, the
issuance function would correspond to the insertion of a key in a
KT log under a user's identity.  The verification function would
correspond to verifying a key's inclusion in the log for a claimed
identity, together with the KT log's mechanisms for a user to
monitor and control which keys are associated with their identity.
Several current messaging applications rely on users verifying
each other's key fingerprints for authentication.  In this
scenario, the issuance function is simply the generation of a key
pair (i.e., a credential is just an identifier and public key,
with no information to assist in verification).  The verification
function is the application functionality that enables users to
verify keys.
In a system based on CONIKS end user Key Transparency (KT), the
issuance function would correspond to the insertion of a key in a
KT log under a user's identity.  The verification function would
correspond to verifying a key's inclusion in the log for a claimed
identity, together with the KT log's mechanisms for a user to
monitor and control which keys are associated with their identity.
Unlike the Authentication Service which is trusted for authentication
and secrecy, the Delivery Service is completely untrusted regarding
this property.  While privacy of group membership might be a problem
in the case of a Delivery Service server fanout, the Delivery Service
can be considered as an active, adaptive network attacker for the
purpose of security analysis.
Unlike the Authentication Service which is trusted for authentication
and secrecy, the Delivery Service is completely untrusted regarding
these properties.  While privacy of group membership might be a
problem in the case of a Delivery Service server fanout, the Delivery
Service can be considered as an active, adaptive network attacker for
the purpose of security analysis.
When a client wishes to establish a group or add clients to a group,
it first contacts the Delivery Service to request KeyPackages for
each other client, authenticates the KeyPackages using the signature
keys, and then uses those to add the other clients to the group.
When a client wishes to establish a group or add clients to a group,
it first contacts the Delivery Service to request KeyPackages for
each other client, authenticates the KeyPackages using the signature
keys, includes the KeyPackages in Add Proposals, encrypts the
information needed to join the group (the _GroupInfo_ object) with an
ephemeral key, then separately encrypts the ephemeral key with the
"init_key" from each KeyPackage.
However, note that a malicious Delivery Service could also reorder
messages or provide an inconsistent view to different users.  The
"generation" counter in MLS messages provides per-sender loss
detection and ordering that cannot be manipulated by the DS.  A
mechanism for more robust protections is discussed in I-D.ietf-mls-
extensions.  A DS can cause a partition in the group by partitioning
key exchange messages; this can be detected only by out of band
comparison (e.g., confirming that all clients have the same
"epoch_authenticator" value`).
However, note that a malicious Delivery Service could also reorder
messages or provide an inconsistent view to different users.  The
"generation" counter in MLS messages provides per-sender loss
detection and ordering that cannot be manipulated by the DS.  A
mechanism for more robust protections is discussed in I-D.ietf-mls-
extensions.  A DS can cause a partition in the group by partitioning
key exchange messages; this can be detected only by out-of-band
comparison (e.g., confirming that all clients have the same
"epoch_authenticator" value`).
MLS is designed as a large-scale group messaging protocol and hence
aims to provide both 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 groups with tens
of thousands of members, typically including many users using
multiple devices.
MLS is designed as a large-scale group messaging protocol and hence
aims to provide both performance and security (e.g. integrity and
confidentiality) to its users.  Messaging systems that implement MLS
provide support for conversations involving two or more members, and
aim to scale to groups with tens of thousands of members, typically
including many users using multiple devices.
The MLS protocol allows each member of the messaging group to perform
operations equally.  This is because all clients within a group
(members) have access to the shared cryptographic material.  However
every service/infrastructure has control over policies applied to its
own clients.  Applications managing MLS clients can be configured to
allow for specific group operations.  On the one hand, an application
could decide that a group administrator will be the only member to
perform add and remove operations.  On the other hand, in many
settings such as open discussion forums, joining can be allowed for
anyone.
The MLS protocol allows each member of the messaging group to perform
operations equally.  This is because all clients within a group
(members) have access to the shared cryptographic material.  However,
every service/infrastructure has control over policies applied to its
own clients.  Applications managing MLS clients can be configured to
allow for specific group operations.  On the one hand, an application
could decide that a group administrator will be the only member to
perform add and remove operations.  On the other hand, in many
settings such as open discussion forums, joining can be allowed for
anyone.
While the Application messages will always be encrypted, having the
handshake messages in plaintext has inconveniences in terms of
privacy as someone could collect the signatures on the handshake
messages and use them for tracking.
While the Application messages will always be encrypted, having the
handshake messages in plaintext has privacy consequences as someone
could collect the signatures on the handshake messages and use them
for tracking.
Within an MLS group, every member is authenticated to other member by
means of credentials issued and verified by the Authentication
Service.  MLS does not prescribe what actions, if any, an application
should take in the event that a group member presents an invalid
credential.  For example, an application may require such a member to
be immediately evicted, or may allow some grace period for the
problem to be remediated.  To avoid operational problems, it is
important for all clients in a group to have a consistent view of
which credentials in a group are valid, and how to respond to invalid
credentials.
Within an MLS group, every member is authenticated to every other
member by means of credentials issued and verified by the
Authentication Service.  MLS does not prescribe what actions, if any,
an application should take in the event that a group member presents
an invalid credential.  For example, an application may require such
a member to be immediately evicted, or may allow some grace period
for the problem to be remediated.  To avoid operational problems, it
is important for all clients in a group to have a consistent view of
which credentials in a group are valid, and how to respond to invalid
credentials.
Delivering messages sent to a group to all members in the
group.
Delivering messages for a group to all members in the group.
Generally, MLS is designed under the assumption that the transport
layer is present to protect metadata and privacy in general, while
the MLS protocol is providing stronger guarantees such as
confidentiality, integrity and authentication guarantees.  Stronger
properties such as deniability can also be achieved in specific
architecture designs.
Generally, MLS is designed under the assumption that the transport
layer is present to keep metadata private from network observers,
while the MLS protocol provides confidentiality, integrity, and
authentication guarantees for the application data (which could pass
through multiple systems).  Additional properties such as partial
anonymity or deniability could also be achieved in specific
architecture designs.
MLS avoids needing to send the full list of recipients to the server
for dispatching messages because that list is potentially extremely
large in MLS.  Header metadata in MLS messages typically consists of
an opaque "group_id", a numerical value to determine the epoch of the
group (the number of changes that have been made to the group), and
whether the message is an application message, a proposal, or a
commit.
Even though some of this metadata information does not consist of
secret payloads, in correlation with other data a network observer
might be able to reconstruct sensitive information.  Using a secure
channel to transfer this information will prevent a network attacker
from accessing this MLS protocol metadata if it cannot compromise the
secure channel.
The MLS protocol provides an authenticated "Additional Authenticated
Data" field for applications to make data available outside the
MLSCiphertext.
MLS avoids needing to send the full list of recipients to the server
for dispatching messages because that list could potentially contain
tens of thousands of recipients.  Header metadata in MLS messages
typically consists of an opaque "group_id", a numerical value to
determine the epoch of the group (the number of changes that have
been made to the group), and whether the message is an application
message, a proposal, or a commit.
Even though some of this metadata information does not consist of
sensitive information, in correlation with other data a network
observer might be able to reconstruct sensitive information.  Using a
secure channel to transfer this information will prevent a network
attacker from accessing this MLS protocol metadata if it cannot
compromise the secure channel.
The MLS protocol provides an authenticated "Additional Authenticated
Data" field for applications to make data available outside a
PrivateMessage.
As noted above, MLS is designed to provide some robustness in the
face of tampering within the secure transport, i.e., tampering by the
Delivery Service.  The confidentiality and authenticity properties of
MLS prevent the DS reading or writing messages.  MLS also provides a
few tools for detecting message suppression, with the caveat that
message suppression cannot always be distinguished from transport
failure.
As noted above, MLS is designed to provide some robustness in the
face of tampering within the secure transport, i.e., tampering by the
Delivery Service.  The confidentiality and authenticity properties of
MLS prevent the DS from reading or writing messages.  MLS also
provides a few tools for detecting message suppression, with the
caveat that message suppression cannot always be distinguished from
transport failure.
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.
FS means that access to all encrypted traffic history combined with
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.
This risk only arises when the leaf nodes for the clients in question
provide data that can be used to correlate the clients.  So one way
to mitigate this risk is by only doing client-level authentication
within MLS.  If user-level authentication is still desirable, the
application would have to be provide it through some other mechanism.
This risk only arises when the leaf nodes for the clients in question
provide data that can be used to correlate the clients.  So one way
to mitigate this risk is by only doing client-level authentication
within MLS.  If user-level authentication is still desirable, the
application would have to provide it through some other mechanism.
The MLS protocol adopts a threat model which includes multiple forms
of endpoint/client compromise.  While adversaries are in a very
strong position if they have compromised an MLS client, there are
still situations where security guarantees can be recovered thanks to
the PCS properties achieved by the MLS protocol.
The MLS protocol adopts a threat model which includes multiple forms
of endpoint/client compromise.  While adversaries are in a strong
position if they have compromised an MLS client, there are still
situations where security guarantees can be recovered thanks to the
PCS properties achieved by the MLS protocol.
In some circumstances, adversaries may have access to specific AEAD
keys and nonces which protect an Application or a Group Operation
message.  While this is a very weak kind of compromise, it can be
realistic in cases of implementation vulnerabilities where only part
of the memory leaks to the adversary.
In some circumstances, adversaries may have access to specific AEAD
keys and nonces which protect an Application or a Group Operation
message.  While this is a limited kind of compromise, it can be
realistic in cases of implementation vulnerabilities where only part
of the memory leaks to the adversary.
MLS provides Post-Compromise Secrecy against an active adaptive
attacker across epochs for AEAD encryption, which means that as soon
as the epoch is changed, if the attacker does not have access to more
secret material they won't be able to access any protected messages
from future epochs.
MLS provides Post-Compromise Security against an active adaptive
attacker across epochs for AEAD encryption, which means that as soon
as the epoch is changed, if the attacker does not have access to more
secret material they won't be able to access any protected messages
from future epochs.
Note that under that compromise scenario, authentication is not
affected in either of these cases.  As every member of the group can
compute the AEAD keys for all the chains (they have access to the
Group Secrets) in order to send and receive messages, the
authentication provided by the AEAD encryption layer of the common
framing mechanism is very weak.  Successful decryption of an AEAD
encrypted message only guarantees that a member of the group sent the
message.
Note that under that compromise scenario, authentication is not
affected in either of these cases.  As every member of the group can
compute the AEAD keys for all the chains (they have access to the
Group Secrets) in order to send and receive messages, the
authentication provided by the AEAD encryption layer of the common
framing mechanism is weak.  Successful decryption of an AEAD
encrypted message only guarantees that a member of the group sent the
message.
Note that this document makes a clear distinction between the way
signature keys and other group shared secrets must be handled.  In
particular, a large set of group secrets cannot necessarily be
assumed to be protected by an HSM or secure enclave features.  This
is especially true because these keys are extremely frequently used
and changed with each message received by a client.
Note that this document makes a clear distinction between the way
signature keys and other group shared secrets must be handled.  In
particular, a large set of group secrets cannot necessarily be
assumed to be protected by an HSM or secure enclave features.  This
is especially true because these keys are frequently used and changed
with each message received by a client.
Note that it is quite easy for legal requests to ask the service
provider for the push-token associated to an identifier and perform a
second request to the company operating the push-notification system
to get information about the device, which is often linked with a
real identity via a cloud account, a credit card or other
information.
Note that with a legal request to ask the service provider for the
push-token associated with an identifier, it is easy to correlate the
token with a second request to the company operating the push-
notification system to get information about the device, which is
often linked with a real identity via a cloud account, a credit card
or other information.
In the past, some systems have had a centralized server generate
signature key pairs and distribute them to clients.  In such cases,
the centralized server is a point of compromise, since it stores
signature private keys that can be used to impersonate clients.  A
better approach is instead to generate signature key pairs in clients
and have them "blessed" by the centralized service, e.g., by having
the service issue a credential binding the key pair to the client's
identity.  In this approach, there is still a risk that the
centralized service will authorize additional key pairs, but it will
not be able to use existing, client-generated private keys.
It is possible for a system to have a centralized server generate
signature key pairs and distribute them to clients.  This is strongly
discouraged.  In such cases, the centralized server is a point of
compromise, since it stores signature private keys that can be used
to impersonate clients.  A better approach is instead to generate
signature key pairs in clients and have them "blessed" by the
centralized service, e.g., by having the service issue a credential
binding the key pair to the client's identity.  In this approach,
there is still a risk that the centralized service will authorize
additional key pairs, but it will not be able to use existing,
client-generated private keys.
Details about how to verify the identity of a client depend on the
MLS Credential type used.  For example, cryptographic verification of
credentials can be largely performed autonomously (e.g. without user
interaction) by the clients themselves for the "x509" Credential
type.  In contrast, when MLS clients use the "basic" Credential type,
a larger degree of trust must be placed in a (likely) centralized
authentication resource, or on out-of-band processes such as manual
verification.