2.1.Delivery Services

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

                       +------------+                      + Delivery     +                      + Service (DS) +                       +-----+------+                    /        +        \             Group**********************************************************                 /          +          \               **                /           |           \              **      +--------+       +----+---+       +--------+     **     + Client 0 +     + Client 1 +     + Client 3 +    **      +--------+       +--------+       +--------+     **     .............................     ............    **     User 0                            User 1          **                                                       **********************************************************

           +-----------------+      +-----------------+          + Deliver Service 1 +    + Deliver Service 2 +          +                   +    +                   +           +-----------------+      +--------+--------+               |         |                   |               |         |                   |      Group***************|*********|*******************|************              |         |                   |          **              |         |                   |          **      +--------+       +--------+       +--------+     **     + Client 0 +     + Client 1 +     + Client 3 +    **      +--------+       +--------+       +--------+     **     .............................     ............    **     User 0                            User 1          **                                                       **********************************************************

2.2.Authentication Service

In a federated environment, authentication becomes more important. While thespecifics of an Authentication Service are out-of-scope for MLS in general, itis important that strong authentication is accessible to all clients of afederated environment. As an example, a shared transparency log like[keytransparency] could be used.¶

3.1.Network protocol between different domains

Cross-domain operations such as sending and receiving messages, fetchingKeyPackages, and querying the Authentication Services have to be part of acommon network protocol that is supported by all domains in a federatedenvironment.¶

5.1.Different Delivery Servers

Different applications operated by different entities can use MLS to exchangeend-to-end encrypted messages. For example, in a messaging applications, clientsof messaging1.tld can encrypt and decrypt end-to-end encrypted messages frommessaging2.tld.¶

5.2.Different client applications

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

6.1.Delivery service

While there is no strict requirement regarding the network topology, there arepractical advantages when clients only connect to their own Delivery Servicerather than to the whole federated environment. This routing strategy canpossibly make the design of a cross-domain network protocol easier in thecontext of access control.¶

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

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

Depending on the functional requirements (such high availability andredundancy), the different Delivery Services can elect a dedicated DeliveryService to be responsible for ordering handshake messages for a certain periodof time. The election process can be repeated when the availability of DeliveryServices change.¶

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

                               +-----------------+         +---------+                         +--> + Deliver Service B + +---> + Client B1 +                         |    +                   +        +---------+                         |     +-----------------+                         |                     +---+-------------+                   +---------+ +---------+        + Deliver Service A + +-------------> + Client A2 ++ Client A1 + +---> +                   +                  +---------+ +---------+         +------+----------+                         |                         |     +-----------------+         +---------+                         +--> + Deliver Service C + +---> + Client C1 +                              +                   +        +---------+                               +-----------------+

6.2.Authentication Service

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

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

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

Depending on the design of the AS of a given client, other, federated clientsmight have to trust that client's service provider to authenticate itscredential. Confidence in authentication provided by service providers ingeneral can be strengthened by using a scheme such as[keytransparency], whichallows both local and federated clients to assert a shared view of theauthentication information provided by the service.¶

In a federated environment, the AS should provide the same degree oftransparency as in a non-federated environment, i.e. end-to-end authenticationshould be possible.¶

7.1.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'tenforce validation of KeyPackages the same way.¶
• Entities might be malicious and act as a threat actor, e.g. might generatefake clients controlled by them.¶

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