jiebi/TextFlow huggingface dataset:
Original text:
IANA is requested to create the following three entries in the existing registry for ExtensionType (defined in RFC8446): <del> encrypted_client_hello(0xfe0b), with "TLS 1.3" column values set </del>  to "CH, HRR, EE", and "Recommended" column set to "Yes". ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set

Reviewer comments:
To be included with . Note that this is a wire-breaking change that should have landed in draft-11, but didn't.
NAME since this will go into the next version of the draft, can we bump everything to the next version here?
Done.
Thanks!
ECHConfig is defined as but the text below it says The intention was to bump ECHConfig.version from 0xfe0a to 0xfe0b for draft-11, but this got missed by URL (I wrote the PR, so I apologize for my part in missing this.) How do folks think we should resolve this? Do we need to cut a new draft with the ambiguity fixed?
Oh whoops, nice catch! Using definitely won't work since the format and corresponding ClientECH extension has changed. I suppose all the implementors could just agree to mentally fix this typo when reading the draft, but may as well cut draft-12. Draft numbers are cheap.
We could try to pick up some editorial changes, too, like those suggested in .
I'd also personally be pretty happy to have in there, but also fine to skip it for what's supposed to be a small bugfix draft snapshot.
+1 I've not checked recent editorial changes but they're probably fine too. S
I'd be happy to take in draft-12 as well, though I'm inclined to think this should strictly be a bugfix/editorial draft. I'd say let's wait until Chris W. gets off back from PTO and let him make the call. Unless we're in a hurry, in which case we could ping one of the other authors to merge our changes and cut a draft.
Closing as resolved.

Revised text:
IANA is requested to create the following three entries in the existing registry for ExtensionType (defined in RFC8446):  <ins> encrypted_client_hello(0xfe0c), with "TLS 1.3" column values set </ins> to "CH, HRR, EE", and "Recommended" column set to "Yes". ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set
Original text:
7. Servers that support ECH play one of two roles, depending on the <del> payload of the "encrypted_client_hello" extension in the ClientHello: </del>  If "ClientECH.type" is "outer", then the server acts as a client- facing server and proceeds as described in client-facing-server to server overwrites the payload of the "encrypted_client_hello" extension with the following string: <del> As above, the payload of "encrypted_client_hello" is expected to be a "ClientECH" with "ClientECH.type" is "inner".  If this is not the case, the backend server MUST abort the handshake with an "illegal_parameter" alert. Note that, in case of HelloRetryRequest, the backend server confirms ECH acceptance twice: first In HelloRetryRequest, as described here; and then in the subsequent ServerHello, as described above. </del>  8.

Reviewer comments:
The requirement to check the ClientHello for an inner ClientECH doesn't make sense because the entire section is already conditioned by observing an inner ClientECH. Also clarify that the client-facing vs. backend server dispatch happens at the initial ClientHello. Switching roles mid-connection will not work very well.

Revised text:
7. Servers that support ECH play one of two roles, depending on the  <ins> payload of the "encrypted_client_hello" extension in the initial ClientHello: </ins> If "ClientECH.type" is "outer", then the server acts as a client- facing server and proceeds as described in client-facing-server to server overwrites the payload of the "encrypted_client_hello" extension with the following string:  <ins> In the subsequent ServerHello message, the backend server sends the accept_confirmation value as described in backend-server. </ins> 8.
Original text:
"encrypted_client_hello" appears in OuterExtensions. <del> OuterExtensions contains duplicate values. </del> The extensions in ClientHelloOuter corresponding to those in OuterExtensions do not occur in the same order.

Reviewer comments:
There are two reasons for this. First, the algorithm in Appendix B for decoding the EncodedClientHelloInner doesn't actually enforce this. Second, aborting on duplicated extensions is slightly stricter than RFC 8446 requires. It states that "[t]here MUST NOT be more than one extension of the same type in a given extension block", but doesn't specify what the receiver does in this case.

Revised text:
"encrypted_client_hello" appears in OuterExtensions.  The extensions in ClientHelloOuter corresponding to those in OuterExtensions do not occur in the same order.
Original text:
The DNS name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct <del> misconfigured clients, as described in handle-server-response. </del>  Clients MUST ignore any "ECHConfig" structure whose public_name is not parsable as a dot-separated sequence of LDH labels, as defined report such connections as successful to the application.  It additionally MUST ignore all session tickets and session IDs presented by the server.  These connections are only used to trigger <del> retries, as described in handle-server-response.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. </del>  6.1.5. all, it will ignore it as required by Section 4.1.2 of RFC8446. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described <del> in handle-server-response. </del>  Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using Depending on whether the client is configured to accept the proxy's certificate as authoritative for the public name, this may trigger <del> the retry logic described in handle-server-response or result in a connection failure.  A proxy which is not authoritative for the public name cannot forge a signal to disable ECH. </del>  9.

Reviewer comments:
Handling server response discusses how to dispatch between accept/reject, but the retry flow is specifically the reject bit.

Revised text:
The DNS name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct  <ins> misconfigured clients, as described in rejected-ech. </ins> Clients MUST ignore any "ECHConfig" structure whose public_name is not parsable as a dot-separated sequence of LDH labels, as defined report such connections as successful to the application.  It additionally MUST ignore all session tickets and session IDs presented by the server.  These connections are only used to trigger  <ins> retries, as described in rejected-ech.  This may be implemented, for instance, by reporting a failed connection with a dedicated error code. </ins> 6.1.5. all, it will ignore it as required by Section 4.1.2 of RFC8446. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described  <ins> in rejected-ech. </ins> Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using Depending on whether the client is configured to accept the proxy's certificate as authoritative for the public name, this may trigger  <ins> the retry logic described in rejected-ech or result in a connection failure.  A proxy which is not authoritative for the public name cannot forge a signal to disable ECH. </ins> 9.
Original text:
Otherwise, if all candidate ECHConfig values fail to decrypt the extension, the client-facing server MUST ignore the extension and <del> 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. </del>  Note that decryption failure could indicate a GREASE ECH extension (see grease-ech), so it is necessary for servers to proceed with the did not include an "encrypted_client_hello" extension, the client- facing server proceeds with the connection as usual.  The server does not decrypt the second ClientHello's ECHClientHello.payload value, if <del> there is one. </del>  Note that a client-facing server that forwards the first ClientHello cannot include its own "cookie" extension if the backend server sends

Reviewer comments:
This assumes the formulation where, on ECH reject, the server is the client-facing server. In other words, backend servers will never get a CH without ECH having been accepted, so GREASE doesn't apply there. cc NAME
cc NAME too, since he had thoughts on this

Revised text:
Otherwise, if all candidate ECHConfig values fail to decrypt the extension, the client-facing server MUST ignore the extension and  <ins> proceed with the connection using ClientHelloOuter, with the following modifications: If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see dont-stick-out for details. If the server is configured with any ECHConfigs, it 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. </ins> Note that decryption failure could indicate a GREASE ECH extension (see grease-ech), so it is necessary for servers to proceed with the did not include an "encrypted_client_hello" extension, the client- facing server proceeds with the connection as usual.  The server does not decrypt the second ClientHello's ECHClientHello.payload value, if  <ins> there is one.  Moreover, if the server is configured with any ECHConfigs, it 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, as described in client-facing-server. </ins> Note that a client-facing server that forwards the first ClientHello cannot include its own "cookie" extension if the backend server sends
Original text:
DISCLAIMER: This draft is work-in-progress and has not yet seen significant (or really any) security analysis.  It should not be used <del> as a basis for building production systems. </del>  Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several ways in which an on-path

Reviewer comments:
Seems useful to note that -13 should be around for a while but still might change later
Yeah that's fine. Ta, S.
How about this simplification based on the outcome from 111? I think it's clear that future changes may occur, so I just dropped that.

Revised text:
DISCLAIMER: This draft is work-in-progress and has not yet seen significant (or really any) security analysis.  It should not be used  <ins> as a basis for building production systems.  This published version of the draft has been designated an "implementation draft" for testing and interop purposes. </ins> Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several ways in which an on-path
Original text:
server.  It SHOULD retry the handshake with a new transport connection, using the retry configurations supplied by the server. The retry configurations may only be applied to the retry connection. <del> The client MUST continue to use the previously-advertised configurations for subsequent connections.  This avoids introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry configurations in order to identify the client in a subsequent ECH handshake. </del>  If none of the values provided in "retry_configs" contains a supported version, the client can regard ECH as securely disabled by

Reviewer comments:
When retry-configs are defined in section 5 we say they are for "subsequent connection attempts" but in 6.1.6 we have a MUST NOT for using those for "subsequent connections." That seems inconsistent and maybe even wrong if one thinks about how e.g. wget can crawl web pages, or how applications might use libcurl, so this change tries to fix that. Not sure if short duration is the right way to phrase it though.

Revised text:
server.  It SHOULD retry the handshake with a new transport connection, using the retry configurations supplied by the server. The retry configurations may only be applied to the retry connection.  <ins> The client MUST NOT use retry configurations for connections beyond the retry.  This avoids introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry configurations in order to identify the client in a subsequent ECH handshake. </ins> If none of the values provided in "retry_configs" contains a supported version, the client can regard ECH as securely disabled by
Original text:
ECHClientHello.config_id since it can be used as a tracking vector. In such cases, the second method should be used for matching the ECHClientHello to a known ECHConfig.  See optional-configs.  Unless <del> specified by the application using (D)TLS or externally configured on both sides, implementations MUST use the first method. </del>  The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension:

Reviewer comments:
said to not use trial decryption unless "externally configured on both sides" but there's no way to know that, so I think the "on both sides" ought be deleted unless something else was intended.

Revised text:
ECHClientHello.config_id since it can be used as a tracking vector. In such cases, the second method should be used for matching the ECHClientHello to a known ECHConfig.  See optional-configs.  Unless  <ins> specified by the application using (D)TLS or externally configured, implementations MUST use the first method. </ins> The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension:
Original text:
An ECHConfigList structure containing one or more ECHConfig structures, in decreasing order of preference, to be used by the <del> client in subsequent connection attempts.  These are known as the </del>  server's "retry configurations". Finally, when the client offers the "encrypted_client_hello", if the

Reviewer comments:
…with reference to Section 6.1.6 See also the discussion on tlswg/draft-ietf-tls-esni.

Revised text:
An ECHConfigList structure containing one or more ECHConfig structures, in decreasing order of preference, to be used by the  <ins> client as described in rejected-ech.  These are known as the </ins> server's "retry configurations". Finally, when the client offers the "encrypted_client_hello", if the
Original text:
interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension can be tagged as mandatory by using <del> an extension type codepoint with the high order bit set to 1.  A client that receives a mandatory extension they do not understand MUST reject the "ECHConfig" content. </del>  Clients MUST parse the extension list and check for unsupported mandatory extensions.  If an unsupported mandatory extension is

Reviewer comments:
I can see how that sentence is redundant, but it seems like it would be helpful to implementers.

Revised text:
interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension can be tagged as mandatory by using  <ins> an extension type codepoint with the high order bit set to 1. </ins> Clients MUST parse the extension list and check for unsupported mandatory extensions.  If an unsupported mandatory extension is
Original text:
The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running <del> on a home router.  "not_before" and "not_after" fields represent the validity period of the published ESNI keys.  Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period.  Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period. </del>  Client MAY cache the ESNIKeys for a particular domain based on the TTL of the Resource Record, but SHOULD NOT cache it based on the not_after value, to allow servers to rotate the keys often and <del> improve forward secrecy (due to clock skew on the client, it may not be possible for the server to use a very short key lifetime).  Note that servers will need to retain the decryption key for some time after not_after to deal with clock skew, internal caches, and the like. </del>  Note that the length of this structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.

Reviewer comments:
I'm not sure this is much better. I would changes the "Note that servers..." sentence to something like:
See URL

Revised text:
The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running  <ins> on a home router. "not_before" and "not_after" fields represent the validity period of the published ESNI keys.  Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period. Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period.  Note that servers will need to retain the decryption key for some time after "not_after" to deal with clock skew, internal caches, and the like. </ins> Client MAY cache the ESNIKeys for a particular domain based on the TTL of the Resource Record, but SHOULD NOT cache it based on the not_after value, to allow servers to rotate the keys often and  <ins> improve forward secrecy. </ins> Note that the length of this structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.
Original text:
such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. <del> [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but would make it so you could not operate a current TLS 1.3 server as a backend server.]] </del> 6. In general, this mechanism is designed only to be used with servers

Reviewer comments:
As per discussion in URL this would require changes to Split Mode backend servers, and it turns out that even for plain "server_name" this behaviour is pretty much useless.

Revised text:
such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key.  6. In general, this mechanism is designed only to be used with servers
Original text:
in the existing registry for ExtensionType (defined in I-D.ietf-tls- tls13), with "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". 

Reviewer comments:
URL is in wglc and seems likely to become a standards track doc. It establishes a registry for undesrscore scoped names it means a blocking reference to ATTRLEAF, but that doesn't seem like a problem time wise

Revised text:
in the existing registry for ExtensionType (defined in I-D.ietf-tls- tls13), with "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". <ins> 8.2. IANA is requested to create an entry in the DNS Underscore Global Scoped Entry Registry (defined in I-D.ietf-dnsop-attrleaf) with the "RR Type" column value being set to "TXT", the "_NODE NAME" column value being set to "_esni", and the "Reference" column value being set to this document. </ins>
Original text:
record for that domain. Clients obtain these records by querying DNS for ESNI-enabled server <del> domains.  Thus, servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client-facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ESNI-enabled server anonymity set.  This probability may be increased via traffic analysis or other mechanisms. </del>  The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running

Reviewer comments:
NAME please have a look!
The order of DNS queries may matter in systems that use Happy Eyeballs. Also, should TLS connections block until ESNI key queries come back? What if they never come back?
can you elaborate on what you're thinking about wrt he? (assuming the URL plan is off the table)
Basically addressed in .

Revised text:
record for that domain. Clients obtain these records by querying DNS for ESNI-enabled server  <ins> domains.  Clients may initiate these queries in parallel alongside normal A or AAAA queries, and SHOULD block TLS handshakes until they complete, perhaps by timing out. Servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client- facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client- facing server can guess the correct SNI with probability at least 1/ K, where K is the size of this ESNI-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. </ins> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running
Original text:
queries example.com, the ESNI TXT name is _esni.example.com.  Servers SHOULD configure DNS such that, upon querying a domain name with ESNI support, at most one A, AAAA, TXT ESNI, and ALTSVC I-D.schwartz- <del> httpbis-dns-alt-svc Resource Record is returned.  Providing more address options and ESNI keys could lead a client to choose an incorrect key for an address.  Alt-Svc records may be used to inform the client of the plaintext (fronting) SNI Also, servers operating in Fronting Mode SHOULD have DNS configured to return the same A (or AAAA) record for all hidden servers they </del>  service. The Resource Record TTL determines the lifetime of the published ESNI

Reviewer comments:
Instead of a Fronting SNI field, we should just re-use the Alt-Svc record, which already carries an SNI value to be used.

Revised text:
queries example.com, the ESNI TXT name is _esni.example.com.  Servers SHOULD configure DNS such that, upon querying a domain name with ESNI support, at most one A, AAAA, TXT ESNI, and ALTSVC I-D.schwartz-  <ins> httpbis-dns-alt-svc Resource Record is returned.  Alt-Svc records may be used to inform the client of the plaintext (fronting) SNI.  Also, servers operating in Fronting Mode SHOULD have DNS configured to return the same A (or AAAA) record for all hidden servers they </ins> service. The Resource Record TTL determines the lifetime of the published ESNI