Change:
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.

Discussion:
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?