jiebi/TextFlow huggingface dataset:
Original text:
"ECHConfig.cipher_suites" list. The configuration identifier, equal to "Expand(Extract("", <del> config), "tls13 ech config id", Nh)", where "config" is the </del>  "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.)

Reviewer comments:
The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.

Revised text:
"ECHConfig.cipher_suites" list. The configuration identifier, equal to "Expand(Extract("",  <ins> config), "tls ech config id", Nh)", where "config" is the </ins> "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.)
Original text:
Note that the HPKE functions Deserialize and SetupBaseS are those which match "ECHConfig.kem_id" and the AEAD/KDF used with "context" are those which match the client's chosen preference from <del> "ECHConfig.cipher_suites". </del>  The value of the "encrypted_client_hello" extension in the ClientHelloOuter is a "ClientECH" with the following values:

Reviewer comments:
The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.

Revised text:
Note that the HPKE functions Deserialize and SetupBaseS are those which match "ECHConfig.kem_id" and the AEAD/KDF used with "context" are those which match the client's chosen preference from  <ins> "ECHConfig.cipher_suites".  The "info" parameter to SetupBaseS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig. </ins> The value of the "encrypted_client_hello" extension in the ClientHelloOuter is a "ClientECH" with the following values:
Original text:
"payload", as computed above.  6.2. This section describes a deterministic padding mechanism based on the

Reviewer comments:
The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.

Revised text:
"payload", as computed above. <ins> If optional configuration identifiers (see optional-configs)) are used, the "config_id" field MAY be empty or randomly generated. Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST compute the field as specified in encrypted-client-hello. </ins> 6.2. This section describes a deterministic padding mechanism based on the
Original text:
of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows: <del> Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </del>  Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon

Reviewer comments:
The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.

Revised text:
of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows:  <ins> The "info" parameter to SetupPSKS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig.  Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </ins> Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon
Original text:
servers set up their HPKE context and decrypt ClientECH as follows: ClientHelloOuterAAD is computed from the second ClientHelloOuter as <del> described in authenticating-outer. </del>  If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH

Reviewer comments:
The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.

Revised text:
servers set up their HPKE context and decrypt ClientECH as follows: ClientHelloOuterAAD is computed from the second ClientHelloOuter as  <ins> described in authenticating-outer.  The "info" parameter to SetupPSKR is computed as above. </ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH
Original text:
ClientHelloInner.  The client-facing server forwards all other TLS messages between the client and backend server unmodified.  7.1.1. In case a HelloRetryRequest (HRR) is sent, the client-facing server

Reviewer comments:
The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.

Revised text:
ClientHelloInner.  The client-facing server forwards all other TLS messages between the client and backend server unmodified. <ins> Otherwise, if all candidate ECHConfigs fail to decrypt the extension, the client-facing server MUST ignore the extension and proceed with the connection using ClientHelloOuter.  This connection proceeds as usual, except the server MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. This allows a server to support multiple versions at once. Note that decryption failure could indicate a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration). Instead, servers can measure occurrences of the "ech_required" alert to detect this case. </ins> 7.1.1. In case a HelloRetryRequest (HRR) is sent, the client-facing server
Original text:
extension but CH1 does not, then the server MUST abort the handshake with an "illegal_parameter" alert. <del> Suppose the "encrypted_client_hello" extension is sent in both CH1 and CH2, If the configuration identifier (see ech-configuration) differs between CH1 and CH2, then the server MUST abort with an "illegal_parameter" alert. </del>  [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified

Reviewer comments:
The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.

Revised text:
extension but CH1 does not, then the server MUST abort the handshake with an "illegal_parameter" alert.  <ins> If the "encrypted_client_hello" extension is sent in CH2, the server follows the procedure in client-facing-server to decrypt the extension, but it uses the previously-selected ECHConfig as the set of candidate ECHConfigs.  If decryption fails, the server aborts the connection with a "decrypt_error" alert rather than continuing the handshake with the second ClientHelloOuter. </ins> [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified
Original text:
ClientHelloInner. The list of HPKE KDF and AEAD identifier pairs clients can use for <del> encrypting ClientHelloInner. </del>  The client-facing server advertises a sequence of ECH configurations to clients, serialized as follows.

Reviewer comments:
Not sure if this is needed, but I guess it would be another way to generate failures;-)
Good clarification! This was already somewhat in the real-ech section, so I just replaced this with a forward pointer there.

Revised text:
ClientHelloInner. The list of HPKE KDF and AEAD identifier pairs clients can use for  <ins> encrypting ClientHelloInner.  See real-ech for how clients choose from this list. </ins> The client-facing server advertises a sequence of ECH configurations to clients, serialized as follows.
Original text:
Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 <del> draft-ietf-tls-md5-sha1-deprecate-04 </del>  Abstract <del> The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </del>  1.

Reviewer comments:
NAME thanks, updated with the additional changes.
NAME NAME NAME Feel free to merge when you get a chance
Great! Now on to Daniel's comments.

Revised text:
Deprecating MD5 and SHA-1 signature hashes in TLS 1.2  <ins> draft-ietf-tls-md5-sha1-deprecate-05 </ins> Abstract  <ins> The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack and this document deprecates their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1.
Original text:
recommendation to use stronger language deprecating use of both SHA-1 and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been <del> deprecated.. </del>  Section 4.3:

Reviewer comments:
NAME thanks, updated with the additional changes.
NAME NAME NAME Feel free to merge when you get a chance
Great! Now on to Daniel's comments.

Revised text:
recommendation to use stronger language deprecating use of both SHA-1 and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been  <ins> deprecated. </ins> Section 4.3:
Original text:
recommended) as defined by RFC8447.  The following entries are to be updated: <del> Other entries of the resgistry remain the same. </del>  9. Concerns with TLS 1.2 implementations falling back to SHA-1 is an <del> issue.  This draft updates the TLS 1.2 specification to deprecate </del>  support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.

Reviewer comments:
NAME thanks, updated with the additional changes.
NAME NAME NAME Feel free to merge when you get a chance
Great! Now on to Daniel's comments.

Revised text:
recommended) as defined by RFC8447.  The following entries are to be updated:  <ins> Other entries of the registry remain the same. </ins> 9. Concerns with TLS 1.2 implementations falling back to SHA-1 is an  <ins> issue.  This document updates the TLS 1.2 specification to deprecate </ins> support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.
Original text:
2. <del> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms extension.  If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used (for example, when using PSK ciphers). </del>  3.

Reviewer comments:
cc NAME NAME NAME
I believe this I-D should still include the "update: 5246 (if approved)" header, even though we took out the 5246 OLD/NEW section. We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5/SHA1 never be sent. In other words, I think you can merge this PR assuming there are no conflicts.
Verifying that this is okay on list, but Daniel suggested the following change for s6: Add the following immediately bfore the OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension.
Resulted in a number of changes - see .
I think you also need to update the abstract and introduction sections, as they both mention "This document updates ..." (same as URL). Will probably conflict with URL so we should merge that first.I believe this can be merged as is. I.e., don't remove the "udpates" header, change the abstract, or intro.

Revised text:
2.  <ins> Clients MUST include the signature_algorithms extension.  Clients MUST NOT include MD5 and SHA-1 in this extension. </ins> 3.
Original text:
4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. </del>  5.

Reviewer comments:
cc NAME NAME NAME
I believe this I-D should still include the "update: 5246 (if approved)" header, even though we took out the 5246 OLD/NEW section. We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5/SHA1 never be sent. In other words, I think you can merge this PR assuming there are no conflicts.
Verifying that this is okay on list, but Daniel suggested the following change for s6: Add the following immediately bfore the OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension.
Resulted in a number of changes - see .
I think you also need to update the abstract and introduction sections, as they both mention "This document updates ..." (same as URL). Will probably conflict with URL so we should merge that first.I believe this can be merged as is. I.e., don't remove the "udpates" header, change the abstract, or intro.

Revised text:
4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.  <ins> If no other signature algorithms are available (for example, if the client does not send a signature_algorithms extension), the server MUST abort the handshake with a handshake_failure alert or select a different cipher suite. </ins> 5.
Original text:
6. <del> RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2, suggests that implementations can assume support for MD5 and SHA-1 by their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. In Section 7.4.1.4.1: the text should be revised from: OLD: "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." NEW: "Note: This is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports SHA-256." 7. </del> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be

Reviewer comments:
cc NAME NAME NAME
I believe this I-D should still include the "update: 5246 (if approved)" header, even though we took out the 5246 OLD/NEW section. We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5/SHA1 never be sent. In other words, I think you can merge this PR assuming there are no conflicts.
Verifying that this is okay on list, but Daniel suggested the following change for s6: Add the following immediately bfore the OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension.
Resulted in a number of changes - see .
I think you also need to update the abstract and introduction sections, as they both mention "This document updates ..." (same as URL). Will probably conflict with URL so we should merge that first.I believe this can be merged as is. I.e., don't remove the "udpates" header, change the abstract, or intro.

Revised text:
6.  The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be
Original text:
[RFC5246][RFC8447][RFC-to-be] <del> 8. </del>  Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This document updates the TLS 1.2 specification to deprecate support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> 9. </del>  The authors would like to thank Hubert Kario for his help in writing the initial draft.  We are also grateful to Daniel Migault, Martin

Reviewer comments:
cc NAME NAME NAME
I believe this I-D should still include the "update: 5246 (if approved)" header, even though we took out the 5246 OLD/NEW section. We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5/SHA1 never be sent. In other words, I think you can merge this PR assuming there are no conflicts.
Verifying that this is okay on list, but Daniel suggested the following change for s6: Add the following immediately bfore the OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension.
Resulted in a number of changes - see .
I think you also need to update the abstract and introduction sections, as they both mention "This document updates ..." (same as URL). Will probably conflict with URL so we should merge that first.I believe this can be merged as is. I.e., don't remove the "udpates" header, change the abstract, or intro.

Revised text:
[RFC5246][RFC8447][RFC-to-be]  <ins> 7. </ins> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This document updates the TLS 1.2 specification to deprecate support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  <ins> 8. </ins> The authors would like to thank Hubert Kario for his help in writing the initial draft.  We are also grateful to Daniel Migault, Martin