Skip to content

Commit

Permalink
Revive draft (#10)
Browse files Browse the repository at this point in the history 
* Revive draft

Co-authored-by: Konrad Kohbrok <[email protected]>
  • Loading branch information
@raphaelrobert @kkohbrok
raphaelrobert and kkohbrok authored May 19, 2022
1 parent cda425a commit 87857e9
Show file tree
Hide file tree
Showing 2 changed files with 143 additions and 170 deletions.
1 change: 1 addition & 0 deletions .gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@
.refcache
.tags
.targets.mk
.vscode
/*-[0-9][0-9].xml
archive.json
report.xml
Expand Down
312 changes: 142 additions & 170 deletions draft-ietf-mls-federation.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -20,110 +20,58 @@ author:
-
ins: R. Robert
name: Raphael Robert
organization: Wire
email: [email protected]

organization:
email: [email protected]

informative:

MLSARCH:
title: "Messaging Layer Security Architecture"
date: 2018
author:
- ins: E. Omara
name: Emad Omara
organization: Google
email: [email protected]
-
ins: R. Barnes
name: Richard Barnes
organization: Cisco
email: [email protected]
-
ins: E. Rescorla
name: Eric Rescorla
organization: Mozilla
email: [email protected]
-
ins: S. Inguva
name: Srinivas Inguva
organization: Twitter
email: [email protected]
-
ins: A. Kwon
name: Albert Kwon
organization: MIT
email: [email protected]
-
ins: A. Duric
name: Alan Duric
organization: Wire
email: [email protected]


MLSPROTO:
title: "Messaging Layer Security Protocol"
date: 2018
author:
- ins: R. Barnes
name: Richard Barnes
organization: Cisco
email: [email protected]
-
ins: J. Millican
name: Jon Millican
organization: Facebook
email: [email protected]
-
ins: E. Omara
name: Emad Omara
organization: Google
email: [email protected]
-
ins: K. Cohn-Gordon
name: Katriel Cohn-Gordon
organization: University of Oxford
email: [email protected]
-
ins: R. Robert
name: Raphael Robert
organization: Wire
email: [email protected]

KeyTransparency:
target: https://KeyTransparency.org
title: Key Transparency
author:
-
ins: Google

keytransparency:
title: Key Transparency
target: https://github.com/google/keytransparency

--- abstract

This document describes how the Messaging Layer Security (MLS) can be used in a federated environment where different MLS
implementations can interoperate by defining the message format for client key retrieval. The document also describes some use
cases where federation could be useful.

This document describes how the Messaging Layer Security (MLS) protocol can be
used in a federated environment.

--- middle

# Introduction

MLS Architecture draft {{MLSARCH}} describes the overall MLS system architecture
assuming the client and servers (Delivery Service and Authentication Service) are operated
by the same entity. This document describes the minimum changes needed to allow different
MLS clients operated by the same or different entities to communicate with each and explaining
The use cases where federation could be useful.
MLS Architecture draft {{!I-D.ietf-mls-architecture}} describes the overall MLS
system architecture, assuming the client and servers (Delivery Service and
Authentication Service) are operated by the same entity. This is however not a
strict requirement, the MLS protocol does not have an inherent dependency on one
single entity and can instead be used between multiple entities.

The focus of this document is on the different components of the MLS
architecture when used in a federated environment.

# Federated environments

Federated environments are environments where multiple entities are operating
independent MLS services. In particular, the assumption is that Delivery
Services and Authentication Services are not necessarily operated by the same
entity.

Entities operating independent MLS services are commonly called domains. In most
cases these domains might correspond to the Domain Name System, but it is not
strictly required. Operating MLS services in a federated environment can
therefore be regarded as federation between different domains.

The focus of this document will be the interaction between the client and the Delivery Service,
specifically how the client retrieves the identityKey and InitKeys for another client.
There is no changes needed for the Authentication Service.
Federation is however not limited to the MLS services themselves. For example, a
federated environment could also contain clients that are provided by different
entities. Specifically, different vendors could provide different applications
that differ in scope and functionality but are interoperable.

Discovering which Delivery service the client communicates with is out of the scope of this document.
## Delivery Services

Depending on the kind of federated environment, the two following types of
federated Delivery Services are possible:

The below diagram shows an MLS group where all clients are operated under the same deliver service:
### Different client applications

The diagram below shows an MLS group where all clients are provided by
potentially different vendors but operate on the same Delivery Service:

~~~~
+------------+
Expand All @@ -145,9 +93,10 @@ The below diagram shows an MLS group where all clients are operated under the sa

~~~~

one possible environment is to have different client implementations operated by the same delivery service,
which will look like the diagram above, another environment is to have different or same clients operated
By different delivery services:
### Different Delivery Services

The diagram below shows a federated environment in which different or identical
clients applications operate on different Delivery Services:

~~~~
+-----------------+ +-----------------+
Expand All @@ -167,58 +116,89 @@ By different delivery services:
* *
*********************************************************

~~~~

## Authentication Service

~~~~
In a federated environment, authentication becomes more important. While the
sepcifics of an Authentication Service are out-of-scope for MLS in general, it
is important that strong authentication is accessible to all clients of a
federated environment. As an example, a shared transparency log like
{{keytransparency}} could be used.

# Further considerations

The following aspects of federated communication are important for successful
federation but are not considered in scope of the MLS charter:

# Terminology
## Common format for the content of application messages

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 {{!RFC2119}} {{!RFC8174}} when, and only when, they appear in all
capitals, as shown here.
The MLS protocol does not impose any format on the content of application
messages. Instead, application messages are considered to be an opaque sequence
of bytes. Applications in a federated environment are expected to agree on a
common format. The negotiation can be done at the KeyPackage level, or through
the MLS extension mechanism.

Client:
: An agent that uses this protocol to establish shared cryptographic
state with other clients. A client is defined by the
cryptographic keys it holds. An application or user may use one client
per device (keeping keys local to each device) or sync keys among
a user's devices so that each user appears as a single client.
## Network protocol between different domains

Client Init Key:
: A short-lived HPKE {{!I-D.irtf-cfrg-hpke}} key pair used to introduce a new
client to a group. Initialization keys are published for
each client (ClientInitKey).
Cross-domain operations such as sending and receiving messages, fetching
KeyPackages, and querying the Authentication Services have to be part of a
common network protocol that is supported by all domains in a federated
environment.

Identity Key:
: A long-lived signing key pair used to authenticate the sender of a
message.
# Discovery service for clients/users on a specific domain

We use the TLS presentation language {{!RFC8446}} to
describe the structure of protocol messages.
Searching for users and other discovery services are typically part of messaging
systems. In the context of MLS, this functionality might overlap with the
fetching of KeyPackages and message routing.

# Use cases

## Different Delivery Servers
Different applications operated by different entities can use MLS to exchange end-to-end encrypted messages.
For example in email applications, clients of email1.com can encrypt and decrypt end-to-end encrypted email messages from email2.com.

Different applications operated by different entities can use MLS to exchange
end-to-end encrypted messages. For example, in a messaging applications, clients
of messaging1.tld can encrypt and decrypt end-to-end encrypted messages from
messaging2.tld.


## Different client applications
Different client applications operated by the same server can use MLS to exchange end-to-end encrypted handshake and application messages.
For example different browsers can implement the MLS protocol, and web developers write web applications that use the MLS
implementation in the browser to encrypt and decrypt the messages. This will require a new standard Web API to allow the
client applications to set the address of the delivery service in the browser. A more concrete example is using MLS in the browser
to negotiate SRTP keys for multi-party conference calls.

Different client applications operating on the same server can use MLS to
exchange end-to-end encrypted handshake and application messages. For example,
different browsers can implement the MLS protocol, and web developers write web
applications that use the MLS implementation in the browser to encrypt and
decrypt the messages. This will require a new standard Web API to allow the
client applications to set the address of the delivery service in the browser. A
more concrete example is using MLS in the browser to negotiate SRTP keys for
multi-party conference calls.

# Functional Requirements

## Delivery service
In a federated environment, the different members of a group might use different Delivery Services. Each client SHOULD only connect to its respective Deliver Service, which in turn will connect to other Delivery Services to relay messages.

One Delivery Service MUST be responsible for handshake message ordering at any given point in time, since TreeKEM requires handshake messages to have a total order. It MUST be clear to all clients and Delivery Services of the group which Delivery Service is responsible. The protocol between different delivery services is out of the scope of this document.
While there is no strict requirement regarding the network topology, there are
practical advantages when clients only connect to their own Delivery Service
rather than to the whole federated environment. This routing strategy can
possibly make the design of a cross-domain network protocol easier in the
context of access control.

In such a topology, the client's own Delivery Service relays messages to the
Delivery Service in charge for a specific group.

When several Delivery Services are involved in relaying messages, it is
important that all of them agree on which one is responsible for ordering
handshake messages of a specific group at any given time in order to enforce the
total ordering of handshake messages required by the MLS protocol.

Depending on the functional requirements (such high availability and
redundancy), the different Delivery Services can elect a dedicated Delivery
Service to be responsible for ordering handshake messages for a certain period
of time. The election process can be repeated when the availability of Delivery
Services change.

The diagram below shows a federated environment where a client connects to its
own Delivery Service that in turn relays messages to other Delivery Services.

~~~~
+-----------------+ +---------+
Expand All @@ -238,58 +218,50 @@ One Delivery Service MUST be responsible for handshake message ordering at any g
 
~~~~

OPEN QUESTION: How server assist could be used with multiple servers? how the server state is shared and synced ?

## Authentication Service
There is no change needed for the Authentication Service, however authentication in a federated environment becomes more important.
The ideal solution would be using a shared transparency log like {{KeyTransparency}}.

# Message format
The encrypted message payload is defined in the MLS protocol document {{MLSPROTO}}, in order to get federation between different systems,
the identity key and client init key retrieval MUST be defined as well. The identity key can always be included in the client init key response.

~~~~~
enum {
P256_SHA256_AES128GCM(0x0000),
X25519_SHA256_AES128GCM(0x0001),
(0xFFFF)
} CipherSuite;

struct {
opaque identity<0..2^16-1>;
CipherSuite supported_suites<0..255>;
} GetClientInitKeyRequest;

struct {
opaque client_init_key_id<0..255>;
CipherSuite cipher_suites<0..255>;
HPKEPublicKey init_keys<1..2^16-1>;
Credential credential;
opaque signature<0..2^16-1>;
} ClientInitKey;

struct {
opaque identity<0..2^16-1>;
ClientInitKey client_init_key;
} ClientInitKeyBundle;
~~~~~

The delivery service will return one or more client init key bundles, one for each member.

~~~~~
struct {
CLientInitKeyBundle client_init_keys<0..2^32-1>;
} GetClientInitKeyResponse;
~~~~~

<!-- OPEN QUESTION: What if different clients have different cipher suites? -->

The MLS specification only describes how the signatures on the contents of the
leaf nodes of a given group can be verified and that clients have to support the
signature schemes of all other clients in each group.

The credential (and thus the binding between identity of the group member and
its signature public key) in each (non-blank) leaf node has to be authenticated
by the AS. This becomes relevant in a federated setting, as the AS, and thus the
authentication process of each member in a given group might differ.

This problem can be solved in a variety of ways, for example, by having all
applications and/or service providers involved in a federation agree on a shared
process, or by having clients advertise their authentication process in a
similar way as their ciphersuite, with the requirement that all members of a
group must support each others authentication processes.

Depending on the design of the AS of a given client, other, federated clients
might have to trust that client's service provider to authenticate its
credential. Confidence in authentication provided by service providers in
general can be strengthened by using a scheme such as {{keytransparency}}, which
allows both local and federated clients to assert a shared view of the
authentication information provided by the service.

In a federated environment, the AS should provide the same degree of
transparency as in a non-federated environment, i.e. end-to-end authentication
should be possible.

# Security Considerations

## Version negotiation
In a federated environment, version negotiation is more critical, to avoid forcing a downgrade attack by
malicious 3rd party delivery services. The negotiation could either be done in the ClientInitKeyBundle or
in a separate handshake message.
## Version & ciphersuite negotiation

In a federated environment, version & ciphersuite negotiation is more critical,
to avoid forcing a downgrade attack by malicious third party Delivery Services.
This is due to the fact that the thread model is extended to include the following:

- Different entities might have diverging security policies, e.g. they don't
enforce validation of KeyPackages the same way.
- Entities might be malicious and act as a threat actor, e.g. might generate
fake clients controlled by them.

The negotiation of version numbers & ciphersuites can be done at the KeyPackage level.

# IANA Considerations

This document makes no requests of IANA.

0 comments on commit 87857e9

Please sign in to comment.