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

[Christopher Patton <[e-mail]>]

Hi Christian,

No, I don't think the server can detect ECH usage by doing that. The
> client will complete the exchange as if connected to the server. The
> client's response would pretty much the same as if the server's response
> had not been modified, and the MITM will not be able to test whether
> this is ECH or not. If it could, ECH would be seriously broken.
>

I think we should be careful with the word "broken" ... here we're talking
about "don't stick out", which is a deployment consideration only. The main
security goal is confidentiality of the ClientHelloInner.


> But there may be some attack plausible by playing with the ciphersuite,
> or maybe the TLS version extension. I don't think so, but I can't prove
> it either way. One solution would be to incorporate more elements in the
> hash. Another would be to serialize the whole server hello, with a
> proforma random, and add to the hint hash the server hello bytes that
> follow the "random" part.
>

The latter seems to be the lowest cost in terms of implementation
complexity. Nevertheless, I continue to believe that its cost outweighs the
benefit of this mechanism. To summarize my reasons:

   1. The class of active attacks it addresses is quite narrow, and we have
   no reason to believe that it poses a deployment risk to ECH. (It certainly
   doesn't invalidate the main security goal.)
   2. We know of much simpler active attacks for distinguishing real ECH
   from cover ECH, which means the intended threat model isn't fully addressed.
   3. Any future mechanism that rigorously addresses the intended threat
   model will replace what we specify today. It seems like good hygiene to
   keep the thing we'll be replacing as simple as possible.

The current proposal (https://github.com/tlswg/draft-ietf-tls-esni/pull/287)
doesn't stick out much to passive attackers, and it even mitigates
(accidental) replay attacks. This ought to be enough to begin experimenting
with deployment. We won't know what the real-world deployment risks are
until we do.

Best,
Chris P.