On Sun, Mar 23, 2025 at 8:59 PM Martin Thomson <m...@lowentropy.net> 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
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
