Draft: draft-ietf-mls-federation

Commentary: Revive draft Co - authored - by :
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.
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.
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.
Discovering which Delivery service the client communicates with is
out of the scope of this document.
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.
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.
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).
A long-lived signing key pair used to authenticate the sender of a
message.
We use the TLS presentation language RFC8446 to describe the
structure of protocol messages.
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.
OPEN QUESTION: How server assist could be used with multiple servers?
how the server state is shared and synced ?
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 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
ClientInitKeyBundle or in a separate handshake message.
This document describes how the Messaging Layer Security (MLS)
protocol can be used in a federated environment.
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 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.