Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla <[e-mail]>]

On Wed, Mar 20, 2024 at 10:39 PM Raghu Saxena <[e-mail]> wrote:

>
> On 3/15/24 00:02, Eric Rescorla wrote:
> >
> >
> >     So, if I understand correctly, for my domain "abc.com
> >     <http://abc.com>", I could
> >     purposely choose to have my ECHConfig public_name be "google.com
> >     <http://google.com>", and
> >
> >
> > As I said earlier, using "google.com <http://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.
>
> Just so I understand correctly - the scope of the attack if they were to
> really intercept the TLS handshake and replace the ECHConfig, would
> allow them to "just" decrypt my ClientHelloInner, correct? Since
> ultimately the real origin I am connecting to (e.g. "mydomain.com") is
> not something they control, and so they can't present a valid cert for
> it and complete the full TLS connection (i.e. impersonate the true origin).
>

Correct.

-Ekr


At least this is what I understand from Section 6.1.7, specifically:
> "Note that authenticating a connection for the public name does not
> authenticate it for the origin. The TLS implementation MUST NOT report
> such connections as successful to the application."
>
> Regards,
>
> Raghu Saxena
>
>