Draft: draft-ietf-mls-architecture

Commentary: Thank you !
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 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 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.
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 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 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.
By definition, the Authentication Service is invested with a large
amount of trust.  A malicious AS can impersonate - or allow an
attacker to impersonate - any user of the system.  As a corrolary, by
impersonating identities authorized to be members of a group, an AS
can break confidentiality.
By definition, the Authentication Service is invested with a large
amount of trust.  A malicious AS can impersonate - or allow an
attacker to impersonate - any user of the system.  As a corollary, by
impersonating identities authorized to be members of a group, an AS
can break confidentiality.
The Delivery Service is also responsible for allowing users to add,
remove or update their initial keying material and to ensure that the
identifier for these keys are unique accross all keys stored on the
DS.
When a client wishes to establish a group, it first contacts the DS
to request a ClientInitKey for each other client, authenticate it
using the signature keys, and then can use those to form the group.
The Delivery Service is also responsible for allowing users to add,
remove or update their initial keying material and to ensure that the
identifier for these keys are unique across all keys stored on the
DS.
When a client wishes to establish a group, it first contacts the DS
to request a KeyPackage for each other client, authenticate it using
the signature keys, and then can use those to form the group.
We assume that all transport connections are secured via some
transport layer security mechanism such as TLS RFC8446.  However, as
noted above, the security of MLS will generally survive compromise of
the transport layer, so long as identity keys provided by the AS are
authenticated at a minimum.  However, MLS ciphertext contain the
Group Identifier, Epoch number and Content Type that may be use to
improve attacks on the privacy of the group.
We assume that all transport connections are secured via some
transport layer security mechanism such as TLS RFC8446.  However, as
noted above, the security of MLS will generally survive compromise of
the transport layer, so long as identity keys provided by the AS are
authenticated at a minimum.  However, MLS ciphertext contains the
Group Identifier, Epoch number and Content Type that may be used to
improve attacks on the privacy of the group.