Draft: draft-ietf-mls-architecture

Commentary: WGLC comments on Security Considerations Section Added discussion about significance of vs. credential types . Moved a paragraph about transport security in general into that section . Made text with list of  consistent with the metadata that is actually present in the protocol now . Moved Metadata Protection for Unencrypted Group Operations heading to just before the two paragraphs that actually discuss it . Added subsection " Integrity and Authentication of Custom Metadata " before the discussion about adding custom metadata to the AAD field . Noted that a websocket connection directly to the DS can be used instead of mobile host platform ( ex : Apple , Google ) native notifications in some environments . Fixed some typos . 
 The automatic checks are failing claiming make lint failed due to trailing whitespace . make lint is running fine in my local copy . I also did a manual search for trailing whitespace and could not fine any . Could someone please   actions ?
MLS avoids needing to send the full list of recipients to the server
for dispatching messages because that list is potentially extremely
large in MLS.  Therefore, the metadata typically consists of a
pseudo-random Group Identifier (GID), a numerical value to determine
the epoch of the group (the number of changes that have been made to
the group), and another numerical value referring to the specific key
needed to decrypt the ciphertext content.
MLS avoids needing to send the full list of recipients to the server
for dispatching messages because that list is potentially extremely
large in MLS.  Header metadata in MLS messages typically consists of
an opaque "group_id", a numerical value to determine the epoch of the
group (the number of changes that have been made to the group), and
whether the message is an application message, a proposal, or a
commit.
More importantly, there is one specific case where having no secure
channel to exchange the MLS messages can have a serious impact on
privacy.  In the case of unencrypted group operation messages,
observing the signatures of the group operation messages may lead an
adversary to extract information about the group memberships.
Having no secure channel to exchange MLS messages can have a serious
impact on privacy when transmitting unencrypted group operation
messages.  Observing the contents and signatures of the group
operation messages may lead an adversary to extract information about
the group membership.
Initial keying material (KeyPackages) using the "basic" Credential
type is more vulnerable to replacement by a malicious or compromised
DS, as there is no built-in cryptographic binding between the
identity and the public key of the client.
To "push" this information to the device, the service provider and
the OS infrastructures use unique per-device, per-application
identifiers called push-tokens.  This means that the push
notification provider and the service provider have information on
which devices receive information and at which point in time.
To "push" this information to the device, the service provider and
the OS infrastructures use unique per-device, per-application
identifiers called push-tokens.  This means that the push
notification provider and the service provider have information on
which devices receive information and at which point in time.
Alternatively, non-mobile applications could use a websocket or
persistent connection for notifications directly from the DS.
One thing for which the MLS Protocol is designed for is to make sure
that all clients know who is in the group at all times.  This means
that - if all Members of the group and the Authentication Service are
honest - no other parties than the members of the current group can
read and write messages protected by the protocol for that Group.
One thing for which the MLS Protocol is designed for is to make sure
that all clients know who is in the group at all times.  This means
that - if all Members of the group and the Authentication Service are
honest - no other parties than the members of the current group can
read and write messages protected by the protocol for that Group.
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.
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.
Compromise scenarios typically consist in a software adversary, which
can maintain active adaptive compromise and arbitrarily change the
behavior of the client or service.
Compromise scenarios typically consist of a software adversary, which
can maintain active adaptive compromise and arbitrarily change the
behavior of the client or service.