jiebi/TextFlow huggingface dataset:
Original text:
addition or removal of group members without informing all other members. <del> Membership of an MLS group is the managed at the level of individual </del>  clients.  In most cases, a client corresponds to a specific device used by a user.  If a user has multiple devices, the user will be represented in a group by multiple clients.  If an application wishes

Reviewer comments:
Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in

Revised text:
addition or removal of group members without informing all other members.  <ins> Membership of an MLS group is managed at the level of individual </ins> clients.  In most cases, a client corresponds to a specific device used by a user.  If a user has multiple devices, the user will be represented in a group by multiple clients.  If an application wishes
Original text:
among parallel groups.  For example, suppose a common member M of two groups A and B has performed a key update in group A but not in group B.  The key update provides PCS with regard to M in group A.  If a <del> PSK exported from group A and injected into group B, then some of </del>  these PCS properties carry over to group B, since the PSK and secrets derived from it are only known to the new, updated version of M, not to the old, possibly compromised version of M.

Reviewer comments:
Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in

Revised text:
among parallel groups.  For example, suppose a common member M of two groups A and B has performed a key update in group A but not in group B.  The key update provides PCS with regard to M in group A.  If a  <ins> PSK is exported from group A and injected into group B, then some of </ins> these PCS properties carry over to group B, since the PSK and secrets derived from it are only known to the new, updated version of M, not to the old, possibly compromised version of M.
Original text:
its prior membership with a PSK. There are a few practical challenges to this approach.  For example, <del> the application will need to ensure that the new members have the </del>  required PSK, including any new members that have joined the group since the epoch in which the PSK was issued.

Reviewer comments:
Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in

Revised text:
its prior membership with a PSK. There are a few practical challenges to this approach.  For example,  <ins> the application will need to ensure that all members have the </ins> required PSK, including any new members that have joined the group since the epoch in which the PSK was issued.
Original text:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> 5.8. Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del>  <del> 5.9. </del>  The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms

Reviewer comments:
Reverts mlswg/mls-architecture This has not been merged for a reason, namely I don’t want the dependency on an unpublished draft.

Revised text:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions.  <ins> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </ins>  <ins> 5.8. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms
Original text:
authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.10. </del>  It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this

Reviewer comments:
Reverts mlswg/mls-architecture This has not been merged for a reason, namely I don’t want the dependency on an unpublished draft.

Revised text:
authentication mechanisms, ciphersuites, and infrastructure functionalities.  <ins> 5.9. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this
Original text:
relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge.  Due to the asynchronous nature of MLS, however, there may be transient <del> inconsistencies in a user's device set, so correlating users' clients </del>  across groups is more of a detection mechanism than a prevention mechanism.

Reviewer comments:
Particularly in multi-device scenarios (where a user has more than one device), we should recommend that clients correlate the set of devices of each user across groups. This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a device credential does not appear in all groups after a while, clients have an indication that the credential might have been created without the user's knowledge. This should however only be a recommendation since it might not be a desirable property in all scenarios. In practical terms, users might also need some time to add their new device to all of the groups, therefore a grace period might be needed. Taking the latter into account, correlating users' devices across groups is more of a detection mechanism than a prevention mechanism.
"In many uses of MLS, there are multiple MLS clients which represent a single user (for example a human user with a mobile and desktop version of an application). Often the same set of clients is represented in exactly the same list groups. In applications where this is the case, clients can compare the set of devices of each user across groups. This would make it much harder for a malicious AS to issue fake device credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a device credential does not appear in all groups after some relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge. As this may take some time, correlating users' devices across groups is more of a detection mechanism than a prevention mechanism."
I lightly edited NAME prose and turned it into PR .
Made a quick pass. I think we should stick with "clients" rather than "devices".

Revised text:
relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge.  Due to the asynchronous nature of MLS, however, there may be transient  <ins> inconsistencies in a user's client set, so correlating users' clients </ins> across groups is more of a detection mechanism than a prevention mechanism.
Original text:
Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the <del> protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). </del>  Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for <del> example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] </del>  analyze the ratcheting tree as the sub-protocol of MLS that <del> facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK21] analyzes the authentication and cross-group healing guarantees provided by MLS. </del>  8. <del> ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACDT19: https://eprint.iacr.org/2019/1189 ACDT21: https://eprint.iacr.org/2021/1083 ACJM20: https://eprint.iacr.org/2020/752 AHKM21: https://eprint.iacr.org/2021/1456 AJM20: https://eprint.iacr.org/2020/1327 BBN19: https://hal.laas.fr/INRIA/hal-02425229 BBR18: https://hal.inria.fr/hal-02425247 BCK21: https://eprint.iacr.org/2021/137 CHK21: https://www.usenix.org/system/files/sec21-cremers.pdf 9. </del> This document makes no requests of IANA.

Reviewer comments:
The references at the end of the Security Considerations weren't in kramdown format. Fixed.

Revised text:
Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the  <ins> protocol has been analyzed by BBN19 (draft 7), ACDT21 (draft 11) and AJM20 (draft 12). </ins> Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for  <ins> example, BBR18, ACDT19, ACCKKMPPWY19, AJM20, ACJM20, and AHKM21 </ins> analyze the ratcheting tree as the sub-protocol of MLS that  <ins> facilitates key agreement, while BCK21 analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, CHK21 analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 8.  This document makes no requests of IANA.
Original text:
KT log under a user's identity.  The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to <del> monitor and control which keys are associated to their identity. </del>  By the nature of its roles in MLS authentication, the AS is invested with a large amount of trust and the compromise of one of its

Reviewer comments:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

Revised text:
KT log under a user's identity.  The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to  <ins> monitor and control which keys are associated with their identity. </ins> By the nature of its roles in MLS authentication, the AS is invested with a large amount of trust and the compromise of one of its
Original text:
is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised. <del> MLS partially defend against this problem by active member including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </del>  <del> *RECOMMENDATION:* Mandate a key updates from clients that are not </del>  otherwise sending messages and evict clients which are idle for too long.

Reviewer comments:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

Revised text:
is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised.  <ins> MLS partially defends against this problem by active members including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </ins>  <ins> *RECOMMENDATION:* Mandate key updates from clients that are not </ins> otherwise sending messages and evict clients which are idle for too long.
Original text:
the secrets themselves are protected by HPKE encryption. Note that under that compromise scenario, authentication is not <del> affected in neither of these cases.  As every member of the group can </del>  compute the AEAD keys for all the chains (they have access to the Group Secrets) in order to send and receive messages, the authentication provided by the AEAD encryption layer of the common

Reviewer comments:
For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.

Revised text:
the secrets themselves are protected by HPKE encryption. Note that under that compromise scenario, authentication is not  <ins> affected in either of these cases.  As every member of the group can </ins> compute the AEAD keys for all the chains (they have access to the Group Secrets) in order to send and receive messages, the authentication provided by the AEAD encryption layer of the common