Change:
Comment by NAME 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 NAME 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 NAME 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 don't see other features being compared to other/older/worse solutions?
Comment by NAME It feels a bit odd to think of a compromised user sending an honest Commit message. If the user doesn't know they are compromised, they will still be compromised and this new Commit message won'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 NAME This "recall" is misplaced. It is not mentioned before until this point.
Comment by NAME 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 NAME It states any "secure channel" can be used, but it is kinda 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 NAME Wouldn'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?

Discussion:
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 <del> has properly implemented the MLS deletion schedule. </del> <ins> 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. </ins> 5.2.

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 <del> since the epoch in which the PSK was issued. </del> <ins> 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. </ins> Reinitializing in this way does not provide the member with access to group messages from during the state loss window, but enables proof

7.1. <del> Any secure channel can be used as a transport layer to protect MLS messages such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </del> <ins> As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure channel can be used as a transport layer to protect MLS messages, such as QUIC, TLS, WireGuard or TOR.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.

and quality of service for MLS. *RECOMMENDATION:* If unidirectional transport is used for the <del> secure transport channel, prefer using a protocol which provides Forward Error Correction. </del> <ins> secure transport channel, prefer using a transport protocol which provides Forward Error Correction. </ins> 7.2.

The attacker has access to all secrets of a user for all groups (full state compromise) <del> 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. </del> <ins> 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. </ins> 7.3.1.

and decrypt all messages for the compromised epochs. If the adversary is passive, it is expected from the PCS properties <del> 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. </del> <ins> 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. </ins> If the adversary is active, the adversary can follow the protocol and perform updates on behalf of the compromised party with no ability

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 <del> epochs until an honest update from the compromised client happens. </del> <ins> epochs, until the compromise is remediated and the formerly compromised client sends an honest update. </ins> Note that under this compromise scenario, the attacker can perform all operations which are available to a legitimate client even

The attacker can publish or distribute credentials <del> 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. </del> <ins> 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. </ins> *RECOMMENDATION:* Make clients submit signature public keys to the AS, this is usually better than the AS generating public key pairs

decrypted during the execution.  Applications should also consider anonymous systems for server fanout (for example Loopix). <del> 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. </del> <ins> 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. </ins> *RECOMMENDATION:* Always use encrypted group operation messages to limit privacy risks.