Re: [TLS] Working Group Last Call for ECH

[Raghu Saxena <[e-mail]>]

On 3/14/24 00:45, Eric Rescorla wrote:
> There are two questions here:
>
> 1. What the specification says
> 2. What implementations choose to do within the envelope of that 
> specification.
>
> The specification needs to prescribe a set of behaviors that promote 
> interoperability, which means that whatever it tells the client to do 
> must be compatible with what it tells servers to do. Presently, the 
> specification tells clients to put whatever is in 
> ECHConfig.public_name in ClientHelloOuter.sni (S 6.1) and tells the 
> server that it may check and reject it otherwise (S 7.1).

So, if I understand correctly, for my domain "abc.com", I could 
purposely choose to have my ECHConfig public_name be "google.com", and 
configure my server to handle it (or ignore the SNI in outer client 
hello altogether), and a client SHOULD NOT try and cancel the ECH 
attempt on seeing that the public_name in ECHConfig does not match the 
host the user is attempting to connect to?

I guess this makes sense, since in the Cloudflare case, every ECHConfig 
advertises public_name as "cloudflare-ech.com", and the user is 
obviously connecting to a different website. In this case I guess it 
isn't as bad, since as a server operator I _could_ choose to just 
piggyback on the public_name of some popular CDN, even though I am not 
using it, to "hide" my real SNI / domain. I think this is a feasible 
workaround.

Regards,

Raghu Saxena