Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla <[e-mail]>]

On Wed, Mar 13, 2024 at 8:40 PM Raghu Saxena <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>