[TLS] Re: checking a bit of ECH behaviour

[David Benjamin <[e-mail]>]

On Sun, Mar 23, 2025 at 8:59 PM Martin Thomson <[e-mail]> wrote:

> On Sun, Mar 23, 2025, at 10:20, David Benjamin wrote:
> > This case is a protocol error and should abort the handshake,
>
> Is it though?  It would appear that the probability of this occurring is
> about 50% after about 4 billion ECH grease handshakes that operate in
> "don't stick out" mode:
> https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-do-not-stick-out
>
> It's probably OK to abort in that case.  The odds are low enough that a
> failed connection is likely preferable to the alternative, but it's
> definitely a non-negligible risk.
>

Hmm, where are you getting those numbers from?

Working backwards, I assume you are thinking of the birthday paradox on
some 64-bit value? The only 64-bit value I can think of is the ServerHello
confirmation signal. Is that the concern? That's not the scenario being
discussed here. As I understand it, the scenario being discussed here is:
1. Client gets a HelloRetryRequest with ECH acceptance signal
2. Client gets a ServerHello without ECH acceptance signal

There is nothing probabilistic going on here. An ECH acceptance signal in
HelloRetryRequest has no "don't stick out" mode. It's just an extension in
HelloRetryRequest. Moreover, the ECH confirmation signal is not subject to
the birthday paradox. We don't care about two random values colliding, but
with the server's random value conflicting with the specific 8 bytes that
the client is expecting. That's a 2^-64 probability, which was discussed
here:
https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-10.9-2

David