Original text:
The "ECHConfig" structure contains the following fields: <del> The version of ECH for which this configuration is used.  The version of this document SHALL be "0xff07".  (Future drafts and the final version MUST define a version that has not already been assigned.)  Clients MUST ignore any "ECHConfig" structure with a version they do not support. </del>  The length, in bytes, of the next field. <del> An opaque byte string whose contents depend on the version of the structure.  For this specification, the contents are an "ECHConfigContents" structure. </del>  The "ECHConfigContents" structure contains the following fields: IANA is requested to create the following two entries in the existing registry for ExtensionType (defined in RFC8446): <del> encrypted_client_hello(0xff02), with "TLS 1.3" column values being </del>  set to "CH, EE", and "Recommended" column being set to "Yes". ech_nonce(0xff03), with the "TLS 1.3" column values being set to 12. Any future information or hints that influence the outer ClientHello <del> SHOULD be specified as ECHConfig extensions, or in an entirely new version of ECHConfig.  This is primarily because the outer ClientHello exists only in support of ECH.  Namely, it is both an envelope for the encrypted inner ClientHello and enabler for authenticated key mismatch signals (see server-behavior).  In contrast, the inner ClientHello is the true ClientHello used upon ECH negotiation. </del> 

Reviewer comments:
Addresses URL
The ECH version is negotiated as follows: the server indicates which versions of ECH it supports by advertising a configuration for each supported version, and the client selects the version by selecting a configuration. The selected configuration is currently indicated by . The structure is defined as follows: Because the negotiated version is determined by the configuration, future versions of ECH that change the structure of --- in particular, the way the selected configuration is indicated--- will break backwards compatibility. Therefore, I would like to propose adding the ECH version to to this structure.
Oh nice catch. I agree that the versioning scheme doesn't work here, though our experience adding extension points inside extension points has not been good. Implementations keep messing them up and we lose the extension point anyway. ("Have one joint and keep it well-oiled.") Do we actually need the versioning scheme after the draft is done? If it weren't for the SVCB code point, I would say we should simply pick different extension code points for each deployed draft. But perhaps we should just do that for the SVCB code point too? If we did that, would we need versions in the first place?
Well, strictly speaking they will only do so if they break the first two fields, right? Because the rest can be conditioned on the config_digest.
True, but to NAME point, I wonder if versioning ECHConfigContents is necessary. Would it be sufficient to update the code point for the draft whenever this changes?
Unless we advertise the version here, we're committing to the first two fields being the same in future versions. Unless we anticipate these changing, let's stick with the status quo.
Each HPKE suite has a fixed-length key encapsulation (), so the length field of is redundant. If we concatenate and into a single opaque field, that might be more future-proof.
I don't see how that helps, since the fields that can't change are ciphersuties and configid.
By way of addressing this issue, I've created a PR that "locks" ECHConfig.version to the extension code point. URL This provides an unambiguous signal of which version of ECH is selected by the client.
I'm not sure the choice of code point (ff08) is available. I picked it because it reflects the next draft (08).
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.

Revised text:
The "ECHConfig" structure contains the following fields:  <ins> The version of ECH for which this configuration is used. Beginning with draft-08, the version is the same as the code point for the "encrypted_client_hello" extension.  Clients MUST ignore any "ECHConfig" structure with a version they do not support. </ins> The length, in bytes, of the next field.  <ins> An opaque byte string whose contents depend on the version.  For this specification, the contents are an "ECHConfigContents" structure. </ins> The "ECHConfigContents" structure contains the following fields: IANA is requested to create the following two entries in the existing registry for ExtensionType (defined in RFC8446):  <ins> encrypted_client_hello(0xff08), with "TLS 1.3" column values being </ins> set to "CH, EE", and "Recommended" column being set to "Yes". ech_nonce(0xff03), with the "TLS 1.3" column values being set to 12. Any future information or hints that influence the outer ClientHello  <ins> SHOULD be specified as ECHConfig extensions.  This is primarily because the outer ClientHello exists only in support of ECH.  Namely, it is both an envelope for the encrypted inner ClientHello and enabler for authenticated key mismatch signals (see server-behavior). In contrast, the inner ClientHello is the true ClientHello used upon ECH negotiation. </ins>