jiebi/CodeConvo huggingface dataset:
Change:
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

Discussion:
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> <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 <del> there is one. </del> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <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:
Change:
…with reference to Section 6.1.6 See also the discussion on tlswg/draft-ietf-tls-esni.

Discussion:
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> <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
Change:
I can see how that sentence is redundant, but it seems like it would be helpful to implementers.

Discussion:
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> <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
Change:
I'm not sure this is much better. I would changes the "Note that servers..." sentence to something like:
See URL

Discussion:
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> <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 <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> <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.
Change:
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.

Discussion:
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
Change:
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

Discussion:
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>
Change:
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 .

Discussion:
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> <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
Change:
Instead of a Fronting SNI field, we should just re-use the Alt-Svc record, which already carries an SNI value to be used.

Discussion:
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> <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
Change:
Do we need it.
For ESNIKeys (the DNS record) I do not think we need a version for the following reasons: I think we would prefer adding extensions rather than making incompatible changes we always have the freedom to pick a new prefix (e.g. ) or a new RR type when making incompatible changes an incompatible change will require the client to query for two DNS records anyways For the ESNI extension, I also do not think that we need a version field. When we define an extension sometime in the future, we could the advertise the support as an extension in the ESNIKeys to instruct the clients that support that extension to send a CH extension that uses a different extension ID than the ESNI extension.
A lot of other TXT records have a version in them. It turns out that if you do that you can query for TXT records and get multiple answers back. Then, you pick those with the version you like. That's one query. I'm tempted to suggest that the first octet (or two) be used for a version number. It's cheap.
I'm concerned about how we iterate on these in the field. They're not tied to TLS version, so what if we decide to change the formats, as we are discussing in
a magic number (including version) is a pretty decent idea. right now _esni is in its own namespace but you can imagine someone doing a txt record that applies to every dns response so we would want to disambiguate that as well. take note to update the "concat multiple records" rule if we go down this path..
I think that having version is a good idea in sense that it allows to do experiments before the standardization completes.

Discussion:
SNI Encryption keys can be published in the DNS using the ESNIKeys structure, defined below. <ins> The version of the structure.  For this specification, that value SHALL be 0x0000.  Clients MUST ignore any ESNIKeys structure with a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]] </ins> The first four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure starting from the first octet of "keys" to the end of the structure.

This structure is placed in the RRData section of a TXT record as a base64-encoded string.  If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings <del> as per Section 3.1.3 of RFC4408. </del> <ins> as per Section 3.1.3 of RFC4408.  Servers MAY supply multiple ESNIKeys values, either of the same or of different versions.  This allows a server to support multiple versions at once. </ins> The name of each TXT record MUST match the name composed of _esni and the query domain name.  That is, if a client queries example.com, the
Change:
Discussed in Singapore; will merge and add security considerations motivation in a followup to .
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
This seems harmless, but it is predicated on a need to separate keys that I don't understand. Is there more rationale somewhere?

Discussion:
4. <ins> To prevent PSK Importers from being confused with standard OOB PSKs we change the label used in the computation of the PSK binder key. In TLS 1.3 the PSK binder key computation is defined as follows: We replace the string "ext binder" with "imp binder".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  The "binder_key" is a leaf key. Therefore, changing its computation doesn't affect any other key. 5. </ins> A key importer takes as input an EPSK with external identity 'external_identity' and base key 'epsk', as defined in terminology, along with an optional label, and transforms it into a set of PSKs

that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. <del> 5. </del> <ins> 6. </ins> For clarity, the following table specifies PSK importer labels for varying instances of the TLS handshake. <del> 6. </del> <ins> 7. </ins> If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they may remove this hash function from the set of hashes used during while importing keys.  This does not affect the KDF operation used to derive concrete PSKs. <del> 7. </del> <ins> 8. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an external PSK may be used with the same

does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. <del> 8. </del> <ins> 9. </ins> This is a WIP draft and has not yet seen significant security analysis. <del> 9. </del> <ins> 10. </ins> DISCLAIMER: This section contains a sketch of a design for protecting external PSK identities.  It is not meant to be implementable as

precompute these obfuscated identities to ease the burden of trial decryption. <del> 10. </del> <ins> 11. </ins> This document makes no IANA requests.
Change:
To make external psk importers more featureful it makes sense to take advantage of the HKDF already in use. By providing a field for extra context we can avoid protocol layering attacks. For example this change allows us to securely bind one TLS session to another, providing layered context.
See: URL
This was addressed with the slot via and . Closing!
Thanks! This is much more understandable than the previous PR. :-)LGTM with the suggested name change!

Discussion:
versions of TLS will increase the number of PSKs derived from an external PSK. <ins> ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a channel binding for the deriving protocols RFC5056.  If any secrets are agreed in earlier protocols they SHOULD be included in ImportedIdentity.context CCB. </ins> A unique and imported PSK (IPSK) with base key 'ipskx' bound to this identity is then computed as follows:
Change:
This isn't perfect either, but it concentrates on the functional side, namely that we use a sequence of bytes to identify PSKs.

Discussion:
Base Key: The secret value of an EPSK. <del> External Identity: The identity of an EPSK. </del> <ins> External Identity: A sequence of bytes used to identify an EPSK. </ins> Target protocol: The protocol for which a PSK is imported for use.

Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. <del> Imported Identity: The identity of an Imported PSK as sent on the wire. </del> <ins> Imported Identity: A sequence of bytes used to identify an IPSK. </ins> 4.
Change:
The gist of the feedback, as I understood it, was that we made claims that were quite strong. This relaxes the language a bit and draws on RFC8446 for some example text. cc NAME NAME NAME
Hard to pick up the differences here, but I think that I got them.

Discussion:
that each PSK only be used with a single hash function.  This was done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm <del> and the TLS 1.2 PRF.  This means that external PSKs could possibly be re-used in two different contexts with the same hash functions during key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. To mitigate these problems, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific KDF and hash function for use in TLS 1.3.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </del> <ins> and the TLS 1.2 PRF.  While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done.  Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions when possible. To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific KDF and hash function for use in (D)TLS 1.3.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol, that are separate from those used in (D)TLS 1.2 and prior versions.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </ins> 2.

Imported PSKs are not used as IKM for two different KDFs. <del> Imported PSKs do not collide with existing PSKs used for TLS 1.2 and below. </del> Imported PSKs do not collide with future protocol versions and KDFs. <ins> There is no known interference between the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions when possible, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.
Change:
It's a bit confusing to use the term "replace" when discussing the string used for derivation. The text only references one of the strings used for derivation where the diagram references two.

Discussion:
PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: <del> Imported PSKs replace the string "ext binder" with "imp binder" when deriving "binder_key".  This means the binder key is computed as follows: </del> <ins> Imported PSKs use the string "imp binder" rather than "ext binder" or "res binder" when deriving "binder_key".  This means the binder key is computed as follows: </ins> This new label ensures a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b)