Draft: draft-ietf-mls-architecture

Commentary: Comment by Again I am confused there are users with expectations of the MLS protocol , which is still in a draft form only ? Is this mixing MLS and non - MLS ? 
 Comment by Is this the equivalent of proprietary IM clients " auto delete " or " view once " type messaging ? " MLS deletation schedule " has not been defined before it is mentioned here . What is this ? 
 It is not the equivalent of " expiring messages " features . It 's a forward security provision . 
 The is defined in the protocol document . Perhaps a pointer would be useful . 
 Comment by This seems a bit of gloating about the MLS protocol / client . Why not just state why the attack is impossible and require that MLS clients do this ? I do n't see other features being compared to other / older / worse solutions ? 
 Comment by It feels a bit odd to think of a compromised user sending an honest Commit message . If the user does n't know they are compromised , they will still be compromised and this new Commit message wo n't help . If the user did know they were compromised and undid that , then sure this honest Commit message helps . I think perhaps " honest Commit " should be expanded and say something about de - compromised client sending a Commit message . My issue with " honest " is that compromised user with a passive attacker is still " honest " . Similarly confusing is : 
 I think these cases mean " formerly compromised " . 
 Comment by This " recall " is misplaced . It is not mentioned before until this point . 
 Comment by Is this saying a protocol within MLS , eg some application protocol ? Or is this saying in this case , do not use MLS but another protocol at the messaging layer ? 
 I understand " a protocol " as " a transport protocol " . Because MLS does not provide FEC , and its integrity checks will fail if the packet is corrupted . 
 Comment by It states any " secure channel " can be used , but it is  says any insecure channel can be used too . It also feels a little odd to describe these properties of MLS in the Security Considerations section , and not like in the introduction . 
 This is no different from how you can run TLS over a bare TCP / IP connection or you can run it over IPsec , and you get better security properties in the latter case . 
 Comment by Would n't this PSK that is the result of a membership be part of the " state lost or corrupted " ? What is the exact kind of failure mode one would address with this ? Also , how often would such a PSK get updated as it needs to be known to add group members ( and doing this too often would I assume lead to long dormant group members from losing access ? ) If one could remove once 's old self without the PSK , than everyone could delete any member ?
An MLS group's secrets change on every change of membership, so each
client only has access to the secrets used by the group while they
are a member.  Messages sent before a client joins or after they are
removed are protected with keys that are not accessible to the
client.  Compromise of a member removed from a group does not affect
the security of messages sent after their removal.  Messages sent
during the client's membership are also secure as long as the client
has properly implemented the MLS deletion schedule.
An MLS group's secrets change on every change of membership, so each
client only has access to the secrets used by the group while they
are a member.  Messages sent before a client joins or after they are
removed are protected with keys that are not accessible to the
client.  Compromise of a member removed from a group does not affect
the security of messages sent after their removal.  Messages sent
during the client's membership are also secure as long as the client
has properly implemented the MLS deletion schedule, which calls for
the secrets used to encrypt or decrypt a message to be deleted after
use, along with any secrets that could be used to derive them.
There are a few practical challenges to this approach.  For example,
the application will need to ensure that all members have the
required PSK, including any new members that have joined the group
since the epoch in which the PSK was issued.
There are a few practical challenges to this approach.  For example,
the application will need to ensure that all members have the
required PSK, including any new members that have joined the group
since the epoch in which the PSK was issued.  And of course, if the
PSK is lost or corrupted along with the member's other state, then it
cannot be used to recover.
Recall that the MLS protocol provides chains of AEAD keys, per sender
that are generated from Group Secrets.  These keys are used to
protect MLS Plaintext messages which can be Group Operation or
Application messages.  The Group Operation messages offer an
additional protection as the secret exchanged within the TreeKEM
group key agreement are public-key encrypted to subgroups with HPKE.
The MLS protocol provides per-sender chains of AEAD keys that are
generated from Group Secrets.  These keys are used to protect MLS
Plaintext messages which can be Group Operation or Application
messages.  The Group Operation messages offer an additional
protection as the secret exchanged within the TreeKEM group key
agreement are public-key encrypted to subgroups with HPKE.
If the adversary is passive, it is expected from the PCS properties
of the MLS protocol that, as soon as an honest Commit message is sent
by the compromised party, the next epochs will provide message
secrecy.
If the adversary is passive, it is expected from the PCS properties
of the MLS protocol that, as soon as the compromised party remediates
the compromise and sends an honest Commit message, the next epochs
will provide message secrecy.
When considering an active adaptive attacker with access to a
signature oracle, the compromise scenario implies a significant
impact on both the secrecy and authentication guarantees of the
protocol, especially if the attacker also has access to the group
secrets.  In that case both secrecy and authentication are broken.
The attacker can generate any message, for the current and future
epochs until an honest update from the compromised client happens.
When considering an active adaptive attacker with access to a
signature oracle, the compromise scenario implies a significant
impact on both the secrecy and authentication guarantees of the
protocol, especially if the attacker also has access to the group
secrets.  In that case both secrecy and authentication are broken.
The attacker can generate any message, for the current and future
epochs, until the compromise is remediated and the formerly
compromised client sends an honest update.
Infrastructures that provide cryptographic material or credentials in
place of the MLS client (which is under the control of the user)
often have the ability to use the associated secrets to perform
operations on behalf of the user, which is unacceptable in many
situations.  Other mechanisms can be used to prevent this issue, such
as the service blessing cryptographic material used by an MLS client.
In the past, some systems have had a centralized server generate
signature key pairs and distribute them to clients.  In such cases,
the centralized server is a point of compromise, since it stores
signature private keys that can be used to impersonate clients.  A
better approach is instead to generate signature key pairs in clients
and have them "blessed" by the centralized service, e.g., by having
the service issue a credential binding the key pair to the client's
identity.  In this approach, there is still a risk that the
centralized service will authorize additional key pairs, but it will
not be able to use existing, client-generated private keys.
Often, expectation from users is that the infrastructure will not
retain the ability to constantly map the user identity to signature
public keys of the MLS protocol.  Some infrastructures will keep a
mapping between signature public keys of clients and user identities.
This can enable an adversary that has compromised the AS (or required
access according to regulation) to monitor unencrypted traffic and
correlate the messages exchanged within the same group.
Some infrastructure keeps a mapping between keys used in the MLS
protocol and user identities.  An attacker with access to this
information due to compromise or regulation can associate unencrypted
group messages (e.g., Commits and Proposals) with the corresponding
user identity.