jiebi/CodeConvo huggingface dataset:
Change:
We now have a proper retry mechanism, so we don't need to prevent clients to connect using expired keys anymore.
NAME notes that the notbefore and notafter fields are there and described, but not really part of the operational notes. Having something there that talks about these, particularly as it relates to clock skew, would be valuable.
(My ~monthly login into URL - this'd be better on the TLS WG list, and I will send mail on this sometime but anyway...) The not-before and not-after fields are a mistake. Same as turned out true for x.509. I was just doing testing where FF nightly barfed on ESNIKeys I'd published for only that non-reason. (There is no overall security win in so-doing, in general.) Creating a tangle between the cadence at which one updates DNS, the ESNIKeys-internal "lifetime" of a key, the DNS TTL and server-state is basically just pointless nonsense. Let's delete those fields from ESNIKeys before we're done and just rely on DNS for what it already does.
Now that has been merged, I agree that there is less need for notbefore and notafter fields. Previously, a client using an expired key led to connection failure, and therefore having these fields were necessary.
Fixed by removing these fields with .
Thank you for the PR. LGTM

Discussion:
If the server supports wildcard names, it SHOULD set this value to 260. <del> The moment when the keys become valid for use.  The value is represented as seconds from 00:00:00 UTC on Jan 1 1970, not including leap seconds. The moment when the keys become invalid.  Uses the same unit as not_before. </del> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in RFC8446; Section 4.2.  The purpose of the field is to provide room

including those caused by intermediaries such as a DNS proxy running on a home router. <del> "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.  If none of the ESNI keys values are acceptable, the client SHOULD behave as if no ESNI records were found. 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 MAY need to retain the decryption key for some time after "not_after", and will need to consider clock skew, internal caches and the like, when selecting the "not_before" and "not_after" values. Client MAY cache the ESNIRecord values for a particular domain based on the TTL of the Resource Record, but SHOULD NOT cache them based on the not_after value of the ESNIKeys structure, to allow servers to rotate the keys often and improve forward secrecy. </del> Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.
Change:
The checksum seems to add little value with the retry mechanism and record_digest. I think we should remove it. See for some context.
The I-D says: "recorddigest : A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure. This hash is computed using the hash function associated with suite." From looking at the NSS code it appears that the recorddigest input is actually the entire ESNIKeys (after base64 decode) including the version and checksum. Is that correct? IOW, does the following also produce the right value (for CF and sha256)? `
proposes removing the checksum, which should clear this up.
Closing since landed. NAME please re-open if this is still an issue!
The hash used in the extension should use the same hash inputs as the checksum. The difference here just makes using this harder.
I support the change, if that makes people feel more comfortable about having the checksum field in ESNIKeys.
I'm not opposed, but it doesn't help as much as you might think, because you need to compute the label with the cipher hash and not (necessarily) with SHA-256.
So, if you take my suggestion in (which I know NAME doesn't like, but we simply disagree about that), then you can identify the ESNI using a truncated hash that is calculated using the cipher hash because it only appears in the context of a handshake. But that just suggests that this is either not-helpful because we chose not to do anything in , or it is not necessary because we did. I'm OK closing this on that basis.
Checksum is now gone. Closing this issue. NAME thanks for filing it!
I agree that we can now and should make this simplification. The PR looks good to me.

Discussion:
a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]] <del> The first four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure.  For the purpose of computing the checksum, the value of the "checksum" field MUST be set to zero. </del> The non-empty name of the entity trusted to update these encryption keys.  This is used to repair misconfigurations, as described in handle-server-response.

query domain name's canonicalized form.  That is, if a client queries example.com, the ESNI Resource Record might be: <del> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running on a home router. </del> <ins> In the event that ESNIKeys is corrupt in transit or otherwise invalid, servers will initiate the retry mechanism described in server-behavior and deliver valid ESNIKeys to clients. </ins> Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.

shared used to derive the ESNI key. A cryptographic hash of the ESNIKeys structure from which the ESNI <del> key was obtained, i.e., from the first byte of "checksum" to the </del> <ins> key was obtained, i.e., from the first byte of "version" to the </ins> end of the structure.  This hash is computed using the hash function associated with "suite".
Change:
I believe it will be helpful to understanding this document to either add "Presentation Language" to this document or link to Presentation Language elsewhere. The TLS/1.3 document has something similar in

Discussion:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, <del> as shown here. </del> <ins> as shown here.  All TLS notation comes from RFC8446; Section 3. </ins> 3.
Change:
[1] URL
Extensibility failed for SNI, no point in repeating that failure. This is less complex:
Are there other ways we expect servers to select certificates? I can imagine a scenario where clients pin server leaf certificates, and hint servers to the right leaf certificate by sending the leaf SPKI hash in the SNI. Would we want to rule something like that out? The Server Name Indication (SNI) extension in TLS has a provision to provide names other than host names[1]. None have even been defined to my knowledge, but it's there. OpenSSL (and possibly others) have had a long-standing bug[2] (fixed in master) that means that different types of names will cause an error. To be clear: I live in a glass house and am not throwing stones; these things happen. However, it means that a huge fraction of the TLS deployment will not be able to accept a different name type should one ever be defined. (This issue might have been caused by the fact that the original[3] spec didn't define the extension in such a way that unknown name types could be skipped over.) Therefore we (i.e. BoringSSL, and thus Google) are proposing to give up on this and implement our parser such that the SNI extension is only allowed to contain a single host name value. (This is compatible with all known clients.) We're assuming that since this is already the de-facto reality that there will be little objection. I'm sending this mostly to record the fact so that, if someone tries to define a new name type in the future, they won't waste their time. If the community wishes to indicate a different type of name in the future, a new extension can be defined. This is already effectively the case because we wouldn't fight this level of incompatibility when there's any other option. (I think the lesson here is that protocols should have a single joint, and that it should be kept well oiled. For TLS, that means that extensions should have minimal extensionality in themselves and that we should generally rely on the main extensions mechanism for these sorts of things.) [1] URL [2] URL – note that the data pointer is not updated. [3] URL Cheers AGL Adam Langley EMAIL URL

Discussion:
A random 16-octet value to be echoed by the server in the "encrypted_server_name" extension. <del> The true SNI, that is, the ServerNameList that would have been sent in the plaintext "server_name" extension. </del> <ins> The true SNI DNS name, that is, the HostName value that would have been sent in the plaintext "server_name" extension.  (NameType values other than "host_name" are unsupported since SNI extensibility failed SNIExtensibilityFailed). </ins> Zero padding whose length makes the serialized PaddedServerNameList struct have a length equal to
Change:
Followup on . Looks like ESNIConfig is the only ESNI structure that has extensions, now that we've delegated the key delivery to HTTPSSVC. Should I avoid reflowing the text?
states: same type in a given extension block. The ESNI draft should probably explicitly restate this for both and . I'd be happy to make a PR if need be. Thanks!
NAME if you could propose text that takes the new ESNIConfig and HTTPSSVC change into account, that'd be great!
Fixed by .

Discussion:
padded_length is greater than 260. A list of extensions that the client can take into consideration <del> when generating a Client Hello message.  The format is defined in RFC8446; Section 4.2.  The purpose of the field is to provide room for additional features in the future.  An extension may be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand must reject the ESNIConfig content. </del> <ins> when generating a Client Hello message.  The purpose of the field is to provide room for additional features in the future.  The format is defined in RFC8446; Section 4.2.  The same 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 may be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand must reject the ESNIConfig content. </ins> Clients MUST parse the extension list and check for unsupported mandatory extensions.  If an unsupported mandatory extension is
Change:
Also define the length of the randomly-generated "encrypted_ch" field.
NAME NAME

Discussion:
GREASE I-D.ietf-tls-grease "encrypted_client_hello" extension as follows: <del> Select a supported cipher suite, named group, and padded_length value.  The padded_length value SHOULD be 260 (sum of the maximum DNS name length and TLS encoding overhead) or a multiple of 16 less than 260.  Set the "suite" field to the selected cipher suite.  These selections SHOULD vary to exercise all supported configurations, but MAY be held constant for successive connections to the same server in the same session. Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM. </del> <ins> Set the "suite" field to a supported cipher suite.  The selection SHOULD vary to exercise all supported configurations, but MAY be held constant for successive connections to the same server in the same session. </ins> Set the "record_digest" field to a randomly-generated string of hash_length bytes, where hash_length is the length of the hash function associated with the chosen cipher suite. <del> Set the "encrypted_client_hello" field to a randomly-generated string of [TODO] bytes. </del> <ins> Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM. Set the "encrypted_ch" field to a randomly-generated string of [TODO] bytes. </ins> If the server sends an "encrypted_client_hello" extension, the client MUST check the extension syntactically and abort the connection with
Change:
At the moment, there is no extensibility in ESNIKeys. That means that if we want to add additional attributes, we would be forced to define a new DNS record that gets queried simultaneously. I think we do not want to do that. Hence the extensions field. The text is tentative; please feel free to change in any ways.
LGTM.
With merged, I wonder if the ESNIKeys struct should just be renamed to something not specific to ESNI, but something more like "generic TLS config in DNS" so that it can be more cleanly reused by unrelated features. "ServerConfiguration" comes to mind from the early TLS 1.3 days.
If we were to re-use these keys for other purposes, that seems fine. However, I'm not sure we want to do that. Semi-static keys, for example, should ideally be separate.
The keys yes, but I imagine the extensions field can hold "arbitrary" data, so while the keys would be ESNI-specific, you could also include extensions that have nothing to do with ESNI.
Thinking about this some more, this would also require changing the "_esni." prefix to something else. In any case I can see how this might be out of scope for this spec. In the end it's a matter of deciding whether future TLS extensions that need similar DNS records, should be able to reuse the same structure (so no additional TXT record with its own prefix would be required), or if they should define their own structure (and have a separate TXT record). I'm happy to close this if it goes too much out of scope.
Right, I think it's verging on being out of scope. What do others think? NAME NAME
My preference goes to keeping the name as-is, considering the fact that the role of ESNIKeys is (at least for the moment) to negotiate properties between the client and the fronting server (not the hidden server), and that the only property we need to negotiate between the two is the information necessary for ESNI protection. It is true that the DNS record can covey properties related to the hidden server (as you know, I've argued for using it to carry the server certificate chain). But IMO that's a change of concept, and I prefer keeping the concept simple for the time being.
Ok.

Discussion:
disadvantage that the server has to retain a table of all the server names it supports.]] <ins> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in I-D.ietf-tls-tls13; Section 4.2.  The purpose of the field is to provide room for additional features in the future; this document does not define any extension. </ins> The semantics of this structure are simple: any of the listed keys may be used to encrypt the SNI for the associated domain name.  The cipher suite list is orthogonal to the list of keys, so each key may
Change:
Addresses . cc NAME
There's no explicit signal indicating that ECHO was negotiated for a connection. Thus, clients must perform trial decryption with both possible handshake keys. If we intend to keep this, then we should crisply state that "don't stick out" is limited to explicit signals, i.e., implicit signals such as size-related information is probably out of scope. (It's certainly an open question what is the "best" padding scheme for handshake messages.) cc NAME

Discussion:
10.4.4. <del> As more clients enable ECHO support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting providers, the presence of ECHO extensions becomes less suspicious and part of common or predictable client behavior.  In other words, if all Web browsers start using ECHO, the presence of this value does not signal suspicious behavior to passive eavesdroppers. Additionally, this specification allows for clients to send GREASE ECHO extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. </del> <ins> The only explicit signal indicating possible use of ECHO is the ClientHello "encrypted_client_hello" extension.  Server handshake messages do not contain any signal indicating use or negotiation of ECHO.  Clients MAY GREASE the "encrypted_client_hello" extension, as described in grease-extensions, which helps ensure the ecosystem handles ECHO correctly.  Moreover, as more clients enable ECHO support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting providers, the presence of ECHO extensions becomes less unusual and part of typical client behavior.  In other words, if all Web browsers start using ECHO, the presence of this value will not signal unusual behavior to passive eavesdroppers. </ins> 10.4.5.
Change:
Addresses . cc NAME
And possibly also include a bit inside ESNIConfig that tells clients whether or not to populate record_digest. (See URL for some relevant definitions.)
Works for me.

Discussion:
10.2. <del> Supporting optional record digests and trial decryption opens oneself up to DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECHO key, in order to force decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </del> <ins> Optional record digests may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension.  In such settings, servers must perform trial decrypt upon receipt of an empty record digest, which may exacerbate DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECHO key, in order to force wasteful decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </ins> 10.3.
Change:
Seeing no pushback on the list, this moves the draft from Experimental to ST.
The design can apply to TLS 1.4 and beyond (presumably).
Done in .

Discussion:
<del> Encrypted ClientHello for TLS 1.3 </del> <ins> TLS Encrypted Client Hello </ins> draft-ietf-tls-esni-latest Abstract <del> This document defines a mechanism for encrypting a TLS 1.3 ClientHello. </del> <ins> This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. </ins> 1.

Encrypted Client Hello (ECH), which allows clients to encrypt the entirety of their ClientHello to a supporting server.  This protects the SNI and other potentially sensitive fields, such as the ALPN <del> list. </del> <ins> list.  This extension is only supported with (D)TLS 1.3 RFC8446 and newer versions of the protocol. </ins> 2.
Change:
Once we have some implementations that interop, we'll go ahead with early codepoint allocation. The new version matches -07, which will be the next draft version we submit. cc NAME NAME
We need to pick some values for the "encryptedclienthello(TBD)" and for the HTTPSSVC RR type before we can do interop. Allocating some values from the private ranges for those before draft-07 is pushed out would be good so we can do some interop testing. (Or for whatever is the next draft for which we want to do interop.)

Discussion:
The ECHConfig structure contains the following fields: The version of the structure.  For this specification, that value <del> SHALL be 0xff03.  Clients MUST ignore any ECHConfig structure with </del> <ins> SHALL be 0xff07.  Clients MUST ignore any ECHConfig structure with </ins> a version they do not understand. An opaque byte string whose contents depend on the version of the

11.1. <del> IANA is requested to create an entry, encrypted_client_hello(0xffce), in the existing registry for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </del> <ins> IANA is requested to create the following two entries in the existing registry for ExtensionType (defined in RFC8446): encrypted_client_hello(57), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". outer_extension(58), with the "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </ins> 11.2.
Change:
The misrouting content no longer applies since the backend server sees the full CH, with the true SNI.

Discussion:
disabled by the server.  It SHOULD retry the handshake with a new transport connection and ECH disabled. <del> [[TODO: Key replacement is significantly less scary than saying that ECH-naive servers bounce ECH off.  Is it worth defining a strict mode toggle in the ECH keys, for a deployment to indicate it is ready for that? ]] </del> Clients SHOULD implement a limit on retries caused by "ech_retry_request" or servers which do not acknowledge the "encrypted_client_hello" extension.  If the client does not retry in

10.6. <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 backend server also only has one identity.  This does, however, change the situation slightly in that the backend server might previously have checked SNI and now cannot (and an attacker can route a connection with an encrypted SNI to any backend server and the TLS connection will still complete).  However, the client is still responsible for verifying the server's identity in its certificate. [[TODO: Some more analysis needed in this case, as it is a little odd, and probably some precise rules about handling ECH and no SNI uniformly?]] 10.7. </del> Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. padding describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage. <del> 10.8. </del> <ins> 10.7. </ins> This section describes the rationale for ECH properties and mechanics as defenses against active attacks.  In all the attacks below, the

of the attacker is to learn private information about the inner ClientHello, such as the true SNI value. <del> 10.8.1. </del> <ins> 10.7.1. </ins> This attack uses the client's reaction to an incorrect certificate as an oracle.  The attacker intercepts a legitimate ClientHello and

needed for encrypting the Certificate message.  Thus, the client will fail to decrypt the Certificate and abort the connection. <del> 10.8.2. </del> <ins> 10.7.2. </ins> This attack aims to exploit server HRR state management to recover information about a legitimate ClientHello using its own attacker-

for equality and changes behavior based on the result can be used as an oracle to learn the client's SNI. <del> 10.8.3. </del> <ins> 10.7.3. </ins> This attack uses resumption PSKs as an oracle for dictionary attacks against a given ClientHello's true SNI.  To begin, the attacker first