Re: [TLS] TLS ECH, how much can the hint stick out?

[Eric Rescorla <[e-mail]>]

On Sat, Sep 12, 2020 at 11:41 AM Christopher Patton <cpatton=
[e-mail]> wrote:

> I agree with Christian. The reason to use the ServerHello.random trick is
> to make real ECH connections look like connections in which the client
> sends a dummy ECH extension to a non-ECH server. In particular, this design
> pattern is needed for property (1).
>

> Property (2) is achievable if the ECH configuration is secret, i.e., if
> the server is deployed in such a way that it does not reveal it speaks ECH
> unless the client offers the right configuration. In particular, the server
> need not publish the ECH config, either via DNS or the ECH retry logic.
> This won't be feasible for the vast majority of deployments.
>

I think this is the key point:
1. If the ECH Config is public, it's trivial to tell whether the client is
trying to do ECH
2. If the ECH Config is public, it's also trivial to tell whether the
server does ECH
3. It's reasonable to expect that if the client is trying to do ECH and the
server does ECH, you will get ECH.

That limits the degree to which it is useful to conceal whether a given
connection is using ECH. From my perspective, the purpose of this piece of
the design is to discourage middleboxes from blindly suppressing ECH, but
at the point where you are willing to actively intercept each connection,
the ECH Config attack seems much easier.  Note that if the deployment
environment changes so that it would be desirable to fold the handshake key
into this value, this can be done later with an ECH Config extension and
will not need to appear on the wire.

-Ekr