Draft: draft-ietf-tls-esni

Commentary: Addresses 
 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 does n'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 were n'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 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 do n't see how that helps , since the fields that ca n'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 . 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  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 ? 
 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 .
Paragraph (version A):
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.
Paragraph (version A):
An opaque byte string whose contents depend on the version of the
structure.  For this specification, the contents are an
"ECHConfigContents" structure.
Paragraph (version B):
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.
Paragraph (version B):
An opaque byte string whose contents depend on the version.  For
this specification, the contents are an "ECHConfigContents"
structure.
Paragraph (version A):
encrypted_client_hello(0xff02), with "TLS 1.3" column values being
set to "CH, EE", and "Recommended" column being set to "Yes".
Paragraph (version B):
encrypted_client_hello(0xff08), with "TLS 1.3" column values being
set to "CH, EE", and "Recommended" column being set to "Yes".