On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena <poiasdpoi...@live.com> wrote:
> > 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 > As I said earlier, using "google.com" would be unwise because it would allow Google to mount an attack where they terminated the connection and replaced the ECHConfig. You should instead use a name that is either unregistrable or that you control. 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? > As long as your server completes ECH, then it doesn't matter that the certificate it presents is not valid for the public_name. However, if you are unable to complete ECH (e.g., you have forgotten the key and want to do the recovery mechanism), then this will cause an error on the client. -Ekr > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
