jiebi/TextFlow huggingface dataset:
Original text:
The format provides a generalized way to attach any additional information to the timestamp.  This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address:

Reviewer comments:
We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks

Revised text:
The format provides a generalized way to attach any additional information to the timestamp. <ins> We refer to this format as the Internet Extended Date/Time Format (IXDTF). </ins> This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address:
Original text:
For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the <del> string in Internet Date/Time Format.  (An application might require the presence of specific suffix tags, though.) </del>  Without further indication, they are also <del> : Even if included in the Internet Date/Time Format string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </del>  A suffix tag may also indicate that it is <del> : The recipient is advised that it MUST not act on the Internet Date/ Time Format string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </del>  <del> Internet Date/Time Format strings such as: </del>  are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for

Reviewer comments:
We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks

Revised text:
For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the  <ins> string in Internet Extended Date/Time Format (IXDTF).  (An application might require the presence of specific suffix tags, though.) </ins> Without further indication, they are also  <ins> : Even if included in the IXDTF string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </ins> A suffix tag may also indicate that it is  <ins> : The recipient is advised that it MUST not act on the Internet Extended Date/Time Format (IXDTF) string unless it can process the suffix tag as specified.  A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </ins>  <ins> IXDTF strings such as: </ins> are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for
Original text:
However, all have an internal inconsistency or an unrecognized suffix key/ <del> value, so a recipient MUST treat the Internet Date/Time Format string as erroneous. </del>  Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking

Reviewer comments:
We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks

Revised text:
However, all have an internal inconsistency or an unrecognized suffix key/  <ins> value, so a recipient MUST treat the IXDTF string as erroneous. </ins> Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking
Original text:
The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix. <del> The extended date/time format is described by the rule "date-time- ext". </del>  "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234.

Reviewer comments:
We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks

Revised text:
The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix.  <ins> The Internet Extended Date/Time Format (IXDTF) is described by the rule "date-time-ext". </ins> "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234.
Original text:
3.2. <del> Here are some examples of Internet extended date/time format. </del>  rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note

Reviewer comments:
We need a name that people will use until they can say RFC9999 timestamps (and maybe even when they can).
"Extended Timestamps" or "Extended Internet Timestamps" ?
RFC 3339 says "Internet Date/Time Format". That is what sedate says at the moment as well, but that can't stay the same. So I'm considering moving to: Internet Date/Time Format Extended The alternative .... Extended Internet Date/Time Format sounds like a date/time format for the Extended Internet (EI is actually in use as "Extensible Internet", which this shouldn't be confused with). I'd rather call it Fritz, but I haven't found a way to retronym this...
Thanks

Revised text:
3.2.  <ins> Here are some examples of Internet Extended Date/Time Format (IXDTF). </ins> rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note
Original text:
4.2.2. <del> [[TODO]] </del>  4.3.

Reviewer comments:
everything else is self-delimiting and is just a source of confusion (5) Replace PSK TODO with an open issue marker (6) use varints instead of remainder of message. Got a bit carried away

Revised text:
4.2.2.  <ins> [[OPEN ISSUE: Limiting this to one value would potentially save some bytes here, at the cost of generality.]] </ins> 4.3.
Original text:
7.2.  I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them. <del> 7.2.1. </del>  Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the

Reviewer comments:
Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.

Revised text:
7.2. <ins> ESNI requires encrypted DNS to be an effective privacy protection mechanism.  However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may reveal the server identity.  Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess.  It may also include implementation- specific traffic for additional information sources as part of verification. Implementations SHOULD avoid leaking information that may identify the server.  Even when sent over an encrypted transport, such requests may result in indirect exposure of the server's identity, such as indicating a specific CA or service being used.  To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation. 7.3. </ins> I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them.  <ins> 7.3.1. </ins> Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the
Original text:
Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. <del> 7.2.2. </del>  This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys

Reviewer comments:
Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.

Revised text:
Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value.  <ins> 7.3.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys
Original text:
by sending different Resource Records containing ESNIRecord and ESNIKeys values with different keys using a short TTL. <del> 7.2.3. </del>  This design requires servers to decrypt ClientHello messages with ClientEncryptedSNI extensions carrying valid digests.  Thus, it is

Reviewer comments:
Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.

Revised text:
by sending different Resource Records containing ESNIRecord and ESNIKeys values with different keys using a short TTL.  <ins> 7.3.3. </ins> This design requires servers to decrypt ClientHello messages with ClientEncryptedSNI extensions carrying valid digests.  Thus, it is
Original text:
server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.2.4. </del>  As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting

Reviewer comments:
Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.

Revised text:
server.  This attack is bound by the number of valid TCP connections an attacker can open.  <ins> 7.3.4. </ins> As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting
Original text:
ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. <del> 7.2.5. </del>  This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.2.6. </del>  This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. <del> 7.2.7. </del>  Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a

Reviewer comments:
Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.

Revised text:
ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly.  <ins> 7.3.5. </ins> This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently.  <ins> 7.3.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks.  <ins> 7.3.7. </ins> Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a
Original text:
client validates the server certificate against the public name before retrying. <del> 7.2.8. </del>  This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols. <del> 7.3. </del>  Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the

Reviewer comments:
Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.

Revised text:
client validates the server certificate against the public name before retrying.  <ins> 7.3.8. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols.  <ins> 7.4. </ins> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the
Original text:
nonce re-use since the client's ESNI key share, and thus the value of Zx, does not change across ClientHello retries.)  [[TODO: label swapping fixes a bug in the spec, though this may not be the best way to deal with HRR.  See https://github.com/tlswg/ draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft- ietf-tls-esni/pull/170 for more details.]]  The client then creates a ClientESNIInner structure: A random 16-octet value to be echoed by the server in the

Reviewer comments:
I got a little tripped up on this point! Maybe you have a better way to explain it.
Thanks, NAME

Revised text:
nonce re-use since the client's ESNI key share, and thus the value of Zx, does not change across ClientHello retries.) <ins> Note that ESNIContents will not be directly transmitted to the server in the ClientHello.  The server will instead reconstruct the same object by obtaining its values from ClientEncryptedSNI and ClientHello. </ins> [[TODO: label swapping fixes a bug in the spec, though this may not be the best way to deal with HRR.  See https://github.com/tlswg/ draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft- ietf-tls-esni/pull/170 for more details.]] <ins> Same value as ClientEncryptedSNI.record_digest. Same value as ClientEncryptedSNI.key_share. Same nonce as ClientHello.random. </ins> The client then creates a ClientESNIInner structure: A random 16-octet value to be echoed by the server in the
Original text:
10.8.6. This design permits servers operating in Split Mode to forward <del> connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. </del>  <del> 10.8.7. Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </del>  Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from <del> the server because the client validates the server certificate against the public name before retrying. </del>  <del> 10.8.8. </del>  This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with <del> multiple protocols. </del>  10.9.

Reviewer comments:
We use a mix of sentence case and title case in the document. The RFC style guide says to use title case. This PR aligns with that. URL Additionally, the ESNI criteria document has changed slightly since the comparison against criteria section was written. I've aligned the titles with the final wording in RFC8744. RFC8744 has also merged "Proper security context" and "Split server spoofing", so I've done the same here. "Support Multiple Protocols" also now talks about transport protocols and ALPN, so I've added a few words about that.

Revised text:
10.8.6. This design permits servers operating in Split Mode to forward  <ins> connections directly to backend origin servers.  The client authenticates the identity of the backend origin server, thereby avoiding unnecessary MiTM attacks. </ins>  <ins> Conversely, assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client-facing server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </ins> Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from  <ins> the client-facing server because the client validates the server certificate against the public name before retrying. </ins>  <ins> 10.8.7. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with  <ins> multiple application and transport protocols.  By encrypting the entire ClientHello, this design additionally supports encrypting the ALPN extension. </ins> 10.9.
Original text:
"encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2. <del> If it supports ECH but does not recognize the configuration specified by the client, then it ignores the extension and </del>  terminates the handshake using the ClientHelloOuter.  This is referred to as "ECH rejection".  When ECH is rejected, the server sends an acceptable ECH configuration in its EncryptedExtensions message. <del> If it supports ECH and recognizes the configuration, then it attempts to decrypt the ClientHelloInner.  It aborts the handshake if decryption fails; otherwise it forwards the ClientHelloInner to the backend, who terminates the connection.  This is referred to as "ECH acceptance". </del>  Upon receiving the server's response, the client determines whether or not ECH was accepted and proceeds with the handshake accordingly.

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:
"encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2.  <ins> If it supports ECH but cannot decrypt the extension, then it </ins> terminates the handshake using the ClientHelloOuter.  This is referred to as "ECH rejection".  When ECH is rejected, the server sends an acceptable ECH configuration in its EncryptedExtensions message.  <ins> If it supports ECH and decrypts the extension, it forwards the ClientHelloInner to the backend, who terminates the connection. This is referred to as "ECH acceptance". </ins> Upon receiving the server's response, the client determines whether or not ECH was accepted and proceeds with the handshake accordingly.