search

tlswg / draft-ietf-tls-esni

TLS Encrypted Client Hello
https://tlswg.github.io/draft-ietf-tls-esni/#go.draft-ietf-tls-esni.html
Other
229 stars 56 forks source link

Will we loosen the ECHConfig.version == ECH-extension-codepoint requirement in the longer term? #595

Closed sftcd closed 7 months ago

sftcd commented 10 months ago

The text that describes ECHConfig.version includes: "Beginning with draft-08, the version is the same as the code point for the "encrypted_client_hello" extension." I guess that'll need wordsmithing a bit before the RFC issues, but I have a question - am I right in assuming that if/when ECHv2 is defined with an extension codepoint of e.g. "0xfe0e" then it'd still be ok to use an ECHConfig with a version of 0xfe0d when emitting an ECHv2 extension in a ClientHello?

That assumes the specifiers of ECHv2 maintain some kind of backwards compatibility of course but I'd be surprised if that weren't done.

Reason to ask now is I'm looking at the #define'd symbols in my code and wondering what code comment to add:-)

ekr commented 7 months ago

This text should just go away once the RFC is published, so I think we can close this. @sftcd

sftcd commented 7 months ago

at this point, close away