Draft: draft-ietf-mls-architecture

Commentary: The Section has three recommendations , but the discussion rambles . The proposed text places topics related to each recommendation before that recommendation . 
 Thanks ! 
 Comment by Why allow this in the MLS protocol ? How can this " typically " be the case of some of the biggest messaging infrastructures ? Clearly those do n't run the MLS protocol ? Perhaps you meant to compare a similar function to the AS in other messaging protocols ? That is , I would clarify what is the issue , what is possible in MLS and how it compares to non - MLS existing deployments . 
 At a high level , MLS was designed to be agnostic about the authentication design , so I do n't think there 's much normative for MLS to say here . With that said , it seems to me that there are two practices here : A centralized / private authority . As the text says , this is very common and seems like a fairly natural design , whether we like it or not . That authority generating keys rather than signing them . That seems bad , and I guess we could discourage it , but it ca n't be enforceably prohibited 
 That was probably meant to be a comparison , yes , but this entire block has been removed through the multiple changes already made anyway . The important part was to describe things as ekr suggested which is already the case and there is already a recommendation to not design a system which generates the keys in the section about the AS .
One important feature of MLS is that all Members know which other
clients are in the group at all times.  If all Members of the group
and the Authentication Service are honest, no parties other than the
members of the current group can read and write messages protected by
the protocol for that Group.
Beware though, the link between the cryptographic identity of the
client and the real identity of the End User is important.  Details
about how to verify the identity of a client depend on the MLS
Credential type used.  For example, cryptographic verification of
credentials can be largely performed autonomously on the clients for
the "x509" Credential type.  In contrast, when MLS clients use the
"basic" Credential type, a larger degree of trust must be placed in a
(likely) centralized authentication resource, or on out-of-band
processes such as manual verification.
One important feature of MLS is that all Members know which other
members are in the group at all times.  If all Members of the group
and the Authentication Service are honest, no parties other than the
members of the current group can read and write messages protected by
the protocol for that Group.
Details about how to verify the identity of a client depend on the
MLS Credential type used.  For example, cryptographic verification of
credentials can be largely performed autonomously on the clients for
the "x509" Credential type.  In contrast, when MLS clients use the
"basic" Credential type, a larger degree of trust must be placed in a
(likely) centralized authentication resource, or on out-of-band
processes such as manual verification.
While the Authentication Service is often very well protected from
external attackers, it might be the case that this service is
compromised.  In such infrastructure, the AS could validate a (or
generate a new) signature keypair for an identity which is not the
expected one.  Because a user can have many MLS clients running the
MLS protocol, it possibly has many signature keypairs for multiple
devices.  Note that when a "basic" Credential is used, the
Authentication Service also needs an out-of-band mechanism to verify
the identity asserted in the Credential.
With some Authentication Service designs, a private or centralized
authority is trusted to validate signature keypairs used in the MLS
protocol.  This is typically the case in some of the biggest
messaging infrastructures.
If the AS is compromised, it could validate a (or generate a new)
signature keypair for an attacker.  Because a user can have many MLS
clients running the MLS protocol, it possibly has many signature
keypairs for multiple devices.  These attacks could be very difficult
to detect.
Note that when a "basic" Credential is used, the Authentication
Service also needs an out-of-band mechanism to verify the identity
asserted in the Credential.