jiebi/TextFlow huggingface dataset:
Original text:
secrecy. If the adversary is active, the adversary can follow the protocol and <del> perform updates on behalf of the compromised party with no ability to an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </del>  messages exchanged in the epochs after the compromised party has been removed.

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:
secrecy. If the adversary is active, the adversary can follow the protocol and  <ins> perform updates on behalf of the compromised party with no ability for an honest group to recover message secrecy.  However, MLS provides PCS against active adaptive attackers through its Remove group operation.  This means that, as long as other members of the group are honest, the protocol will guarantee message secrecy for all </ins> messages exchanged in the epochs after the compromised party has been removed.
Original text:
epochs until an honest update from the compromised client happens. Note that under this compromise scenario, the attacker can perform <del> all operations which are available to an legitimate client even </del>  without access to the actual value of the signature key. Without access to the group secrets, the adversary will not have the

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:
epochs until an honest update from the compromised client happens. Note that under this compromise scenario, the attacker can perform  <ins> all operations which are available to a legitimate client even </ins> without access to the actual value of the signature key. Without access to the group secrets, the adversary will not have the
Original text:
compromised parties refresh their credentials securely. Beware that in both oracle and private key access, an active adaptive <del> attacker, can follow the protocol and request to update its own </del>  credential.  This in turn induces a signature key rotation which could provide the attacker with part or the full value of the private key depending on the architecture of the service provider.

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:
compromised parties refresh their credentials securely. Beware that in both oracle and private key access, an active adaptive  <ins> attacker can follow the protocol and request to update its own </ins> credential.  This in turn induces a signature key rotation which could provide the attacker with part or the full value of the private key depending on the architecture of the service provider.
Original text:
notification provider have to be trusted to avoid making correlation on which devices are recipients of the same message. <del> For secure messaging systems, push notification are often sent real- </del>  time as it is not acceptable to create artificial delays for message retrieval.

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:
notification provider have to be trusted to avoid making correlation on which devices are recipients of the same message.  <ins> For secure messaging systems, push notifications are often sent real- </ins> time as it is not acceptable to create artificial delays for message retrieval.
Original text:
5.5. <del> Within an MLS group, every member is authenticated to other member, by means of credentials issued and verified by the Authentication </del>  Service.  MLS does not prescribe what actions, if any, an application should take in the event that a group member presents an invalid credential.  For example, an application may require such a member to

Reviewer comments:
NAME noted in URL that an important function of the AS is to ensure that clients come to consistent evaluations of credentials. We should make that recommendation in this document, including the fact that consistency is needed when validity can change over time.

Revised text:
5.5.  <ins> Within an MLS group, every member is authenticated to other member by means of credentials issued and verified by the Authentication </ins> Service.  MLS does not prescribe what actions, if any, an application should take in the event that a group member presents an invalid credential.  For example, an application may require such a member to
Original text:
In some authentication systems, it is possible for a previously-valid credential to become invalid over time.  For example, in a system based on X.509 certificates, credentials can expire or be revoked. <del> Fortunately, the MLS update mechansisms allow a client to replace an old credential with a new one.  This is best done before the old credential becomes invalid. </del>  *RECOMMENDATION:* Proactively rotate credentials, especially if a credential is about to become invalid.

Reviewer comments:
NAME noted in URL that an important function of the AS is to ensure that clients come to consistent evaluations of credentials. We should make that recommendation in this document, including the fact that consistency is needed when validity can change over time.

Revised text:
In some authentication systems, it is possible for a previously-valid credential to become invalid over time.  For example, in a system based on X.509 certificates, credentials can expire or be revoked.  <ins> The MLS update mechanisms allow a client to replace an old credential with a new one.  This is best done before the old credential becomes invalid. </ins> *RECOMMENDATION:* Proactively rotate credentials, especially if a credential is about to become invalid.
Original text:
restricted to certain users, but we assume that those restrictions are enforced by the application layer. <del> 2.1. </del>  While informally, a group can be considered to be a set of users possibly using multiple endpoint devices to interact with the Service

Reviewer comments:
This replaced PR which has broken merge conflicts.
I've reverted this. It was prematurely merged. I'll open a new PR once I have had time to examine this.
This was discussed in the interim today and is the same as the content that was in . Thanks, -rohan Rohan Mahy l Vice President Engineering, Architecture Chat: NAME on Wire Wire - Secure team messaging. Zeta Project Germany GmbH l Rosenthaler Straße 40, 10178 Berlin, Germany Geschäftsführer/Managing Director: Alan Duric HRB 149847 beim Handelsregister Charlottenburg, Berlin VAT-ID DE288748675
That's fine, but I still want to go over it before it merges.

Revised text:
restricted to certain users, but we assume that those restrictions are enforced by the application layer.  <ins> 2.3. </ins> While informally, a group can be considered to be a set of users possibly using multiple endpoint devices to interact with the Service
Original text:
RFC EDITOR PLEASE DELETE THIS SECTION.  draft-03 Added ciphersuites and signature schemes (*)

Reviewer comments:
This does not handle the removal of DH uses instead of KEM which will be done as part of Issue / PR ...
I would be happier if this PR were moving the draft to use draft-barnes-cfrg-hpke, which is one of the changes I had in mind for -04. Do you think that's premature?
This text is wrong:
This could also be addressed by using draft-barnes-cfrg-hpke.
This has been fixed by
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today

Revised text:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-04 ECIES is now renamed in favor of HPKE (*) </ins> draft-03 Added ciphersuites and signature schemes (*)
Original text:
ciphertext in the list is the encryption to the corresponding node in the resolution. <del> The ECIESCiphertext values encoding the encrypted secret values are computed as follows: Generate an ephemeral DH key pair (x, x*G) in the DH group specified by the ciphersuite in use Compute the shared secret Z with the node's other child Derive a key and nonce as described below Encrypt the node's secret value using the AEAD algorithm specified by the ciphersuite in use, with the following inputs: Key: The key derived from Z Nonce: The nonce derived from Z Additional Authenticated Data: The empty octet string Plaintext: The secret value, without any further formatting Encode the ECIESCiphertext with the following values: ephemeral_key: The ephemeral public key x*G ciphertext: The AEAD output </del>  Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted

Reviewer comments:
This does not handle the removal of DH uses instead of KEM which will be done as part of Issue / PR ...
I would be happier if this PR were moving the draft to use draft-barnes-cfrg-hpke, which is one of the changes I had in mind for -04. Do you think that's premature?
This text is wrong:
This could also be addressed by using draft-barnes-cfrg-hpke.
This has been fixed by
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today

Revised text:
ciphertext in the list is the encryption to the corresponding node in the resolution.  <ins> The HPKECiphertext values are computed according to the Encrypt function defined in HPKE. </ins> Decryption is performed in the corresponding way, using the private key of the resolution node and the ephemeral public key transmitted
Original text:
The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the current state using the Add message.  This information is encrypted <del> for the new member using ECIES.  The recipient key pair for the ECIES </del>  encryption is the one included in the indicated UserInitKey, corresponding to the indicated ciphersuite.

Reviewer comments:
This does not handle the removal of DH uses instead of KEM which will be done as part of Issue / PR ...
I would be happier if this PR were moving the draft to use draft-barnes-cfrg-hpke, which is one of the changes I had in mind for -04. Do you think that's premature?
This text is wrong:
This could also be addressed by using draft-barnes-cfrg-hpke.
This has been fixed by
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today

Revised text:
The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the current state using the Add message.  This information is encrypted  <ins> for the new member using HPKE.  The recipient key pair for the HPKE </ins> encryption is the one included in the indicated UserInitKey, corresponding to the indicated ciphersuite.
Original text:
simply copy all fields except the "leaf_secret" from its GroupState object. <del> [[ OPEN ISSUE: The Welcome message needs to be sent encrypted for the new member.  This should be done using the public key in the UserInitKey, either with ECIES or X3DH. ]] </del> [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the Add succeeds, and is not in conflict with another, simultaneous Add.

Reviewer comments:
This does not handle the removal of DH uses instead of KEM which will be done as part of Issue / PR ...
I would be happier if this PR were moving the draft to use draft-barnes-cfrg-hpke, which is one of the changes I had in mind for -04. Do you think that's premature?
This text is wrong:
This could also be addressed by using draft-barnes-cfrg-hpke.
This has been fixed by
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today

Revised text:
simply copy all fields except the "leaf_secret" from its GroupState object.  [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the Add succeeds, and is not in conflict with another, simultaneous Add.
Original text:
each Participant creates an initial Participant Application Secret to be used for its own sending chain: <del> Note that [sender] represent the uint32 value encoding the index of the participant in the ratchet tree. </del>  Updating the Application secret and deriving the associated AEAD key and nonce can be summarized as the following Application key schedule

Reviewer comments:
Fix for
NAME This might not be completely ideal, because of the group state but it currently does not change the key schedule, I am merging this because we need it for correct interop but feel free to get back to discuss a better way to do this in details.
There are at least two bugs in the message protection section that make it unimplementable: It calls for , but the third argument to as defined is a , not an octet string. It refers to a function , which is defined in TLS, but not here. ISTM the simplest way to fix these problems would to define and use it (1) as the basis for , (2) for deriving sender root secrets, and (3) for deriving keys and nonces.
Fixed by

Revised text:
each Participant creates an initial Participant Application Secret to be used for its own sending chain:  <ins> Note that [sender] represents the index of the member in the roster. </ins> Updating the Application secret and deriving the associated AEAD key and nonce can be summarized as the following Application key schedule
Original text:
Rename the GroupState structure to GroupContext (*)  draft-05 Common framing for handshake and application messages (*)

Reviewer comments:
Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.

Revised text:
Rename the GroupState structure to GroupContext (*) <ins> Rename UserInitKey to ClientInitKey </ins> draft-05 Common framing for handshake and application messages (*)