Draft: draft-ietf-mls-federation

Commentary: Addressed SV 's comments  the client fanout concept ( because of TreeKEM 's handshake ordering requirements ) Rename UserInitKeys to ClientInitKeys Minor editorial edits 
 drop client fanout specify why ( policy enforcement , metadata protection ) incorporated comments from SV check if it is necessary to define server - to - server message formats only one domain is responsible for a group 
 I 'm very interested in the details of this , but was unable to attend the interim meeting . Does this mean that we are explicitly ruling out client fanout entirely ? What metadata are we trying to protect here ? You could in theory protect all the metadata with client fanout over Tor for example . Does domain here mean domain name ? Why is that relevant ? ( I 'd expect MLS to be independent of DNS ) The kind of federated delivery service I 'm hoping to be able to use with MLS is logically an append only list of messages published by each member . Where each member can read any other members queue and pull messages they do n't have into their own queue ( they push their own messages to their own queue only ) . This allows for diverse P2P topologies , and bandwidth efficient routing . This would be compatible with both and . 
 TreeKEM has the requirement of total ordering of handshake messages which does n't work with client fanout . Therefore we drop the idea of client fanout until we have a better proposal on how to solve this . is more conceptual , it does n't have to be an actual domain name . 
 Addressed in .
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 user key
retrieval.  The document also describes some use cases where
federation could be useful.
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.
A short-lived HPKE key pair used to introduce a new client to a
group.  Initialization keys are published for each client
(UserInitKey).
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).
Different applications operated by different entities can use MLS to
exchange E2EE messages.  For example in email applications, clients
of email1.com can encrypt and decrypt E2EE email messages from
email2.com.
Different client applications operated by the same server can use MLS
to exchange E2EE 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 exchange SRTP keys for multi-party
conference call.
In MLS environment the messages can either be delivered using client
fanout or server fanout, each will have different requirements.
In a federated environment the client may communicate with one or
more delivery services.  Discovering the delivery service and syncing
between different delivery services are out of scope of this
document.
In this mode, the client SHOULD support communicating with multiple
delivery services.  Discovering the delivery service is out of scope
of this document.
In this mode, the delivery service SHPULD be stateless, and it the
clients responsibility to maintain the group state.  OPEN QUESTION:
How ordering could be enforced in this mode?
Multiple delivery services can be avoided, with server side fan out,
and all keys requests can be proxied through a single delivery
service.  The protocol between different delivery services is out of
the scope of this document.
There is no change needed for the authentication service, however the
authentication in a federated environment becomes more important.
The ideal solution would be using a shared transparency log like
KeyTransparency.
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 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.
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.
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.
The encrypted message payload is defined in the MLS protocol document
MLSPROTO, in order to get federation between different systems, the
identity key and user init key retrieval MUST be defined as well.
The identity key can always be included in the user init key
response.
The delivery service will return one or more user init key bundles,
one for each member.
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.
The delivery service will return one or more client init key bundles,
one for each member.
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
UserInitKeyBundle or in a separate handshake message.
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.