Hey Dennis, On 10/6/23 19:31, Dennis Jackson wrote:
Hi Raghu,On 06/10/2023 10:45, Raghu Saxena wrote:Specifically, I am concerned about the "public name" field in the ECHConfig. For services such as cloudflare, they can "hide" everything behind a single domain (e.g. "cloudflare-ech.com"). However, for someone who just owns a single domain (e.g. "hub.com"), what would the "suggested value" be?The server needs to be able to answer a TLS connection for the ECH public name or you risk an outage if the ECHConfigs get out of sync as then clients will get a TLS error page if they can't get through to the public name.Section 6.1.7 implies it should NOT be an IPv4 address. If I do not wish to leak the real domain, is it "acceptable" to use something like "fakedomain.com"?
If I understand correctly, it would use the ECH `config_id` to determine which ECHConfig to use for determining how to decrypt the ClientHelloInner. So do you mean to say the server should be able to handle a non-ECH TLS connection (e.g. TLS v1.2) for the `public_name` as well? I'd think for non-ECH clients, they would not use the server's ECHConfig at all, so the public_name is irrelevant.
Section 6.1.7 also says if ECH is rejected, the server continues with a "normal" TLS handshake with the `public_name`. However, would it not be desirable for some server administrators to "only allow" ECH, and not allow other TLS handshakes? (Accepting the fact that some clients may fail to connect).
Regards, Raghu
OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
