Draft: draft-ietf-mls-architecture

Commentary: cc ./
Messaging Layer Security (MLS) specifies an architecture (this
document) and an abstract protocol MLSPROTO 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 a
concrete protocol such as XMPP RFC6120.  In addition, it does not
specify a complete wire encoding, but rather a set of abstract data
structures which can then be mapped onto a variety of concrete
encodings, such as TLS RFC8446, CBOR RFC7049, and JSON RFC7159.
Implementations which adopt compatible encodings will have some
degree of interoperability at the message level, though they may have
incompatible 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 an abstract protocol MLSPROTO 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.  In addition, it does not specify a
complete wire encoding, but rather a set of abstract data structures
which can then be mapped onto a variety of concrete encodings, such
as TLS RFC8446, CBOR RFC7049, and JSON RFC7159.  Implementations
which adopt compatible encodings will have some degree of
interoperability at the message level, though they may have
incompatible 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.
In many systems, the AS and the DS are actually operated by the same
entity and may even be the same server.  However, they are logically
distinct and, in other systems, may be operated by different
entities, hence we show them as being separate here.  Other
partitions are also possible, such as having a separate directory
server.
In many systems, the AS and the DS are actually operated by the same
entity and may even be the same server.  However, they are logically
distinct and, in other systems, may be operated by different
entities, hence we show them as being separate entities here.  Other
partitions are also possible, such as having a separate directory
server.
Formally, a Client is a set of cryptographic objects composed by
public values such as a name (an identity), a public encryption key
and a public signature key.  Ownership of a Client by a user is
determined by the fact that the user has knowledge of the associated
secret values.  When a Client is part of a Group, it is called a
Member and its signature key pair uniquely defines its identity to
other clients or members a the Group.  In some messaging systems,
clients belonging to the same user must all share the same identity
key pair, but MLS does not assume this.
Formally, a Client is a set of cryptographic objects composed by
public values such as a name (an identity), a public encryption key
and a public signature key.  Ownership of a Client by a user is
determined by the fact that the user has knowledge of the associated
secret values.  When a Client is part of a Group, it is called a
Member and its signature key pair uniquely defines its identity to
other clients or members in the Group.  In some messaging systems,
clients belonging to the same user must all share the same identity
key pair, but MLS does not assume this.
The formal definition of a Group in MLS is the set of clients that
have knowledge of the shared group secret established in the group
key establishment phase of the protocol and have contributed to it.
Until a Member has contributed to the group secret, other members
cannot assume she is a member of the group.
The formal definition of a Group in MLS is the set of clients that
have knowledge of the shared group secret established in the group
key establishment phase of the protocol and have contributed to it.
Until a Member has contributed to the group secret, other members
cannot assume they are a member of the group.
The MLS protocol assumes a signature keypair for authentication of
messages.  It is important to note that this signature keypair might
be the identity keypair directly, or a different signature keypair
for which the public key has been for example signed by the identity
private key.  This flexibility allows for multiple infrastructure
considerations and has the benefit of providing ways to use different
signature keys across different groups by using hierarchical
authentication keys.  This flexibility also comes at the price of a
security tradeoff, described in the security considerations, between
potential unlinkability of the signature keys across groups and the
amount of time required to reinstate authentication and secrecy of
messages after the compromise of a device.
The MLS protocol assumes a signature keypair for authentication of
messages.  It is important to note that this signature keypair might
be the identity keypair itself, or a different signature keypair for
which the public key has been, for example, signed by the identity
private key.  This flexibility allows for multiple infrastructure
considerations and has the benefit of providing ways to use different
signature keys across different groups by using hierarchical
authentication keys.  This flexibility also comes at the price of a
security tradeoff, described in the security considerations, between
potential unlinkability of the signature keys across groups and the
amount of time required to reinstate authentication and secrecy of
messages after the compromise of a device.