Hiya,
I agree with your analysis except for the very last part... On 19/03/2021 23:59, Christian Huitema wrote:
We do have new information that this is somewhat costly to implement because it requires computing two handshake secrets on the client. On the other hand, it seems that the cost is only there if the client starts by testing the wrong hypothesis. If the client is fairly certain that the server supports ECH, the CPU overhead ought to be minimal -- cases in which the client is using the wrong ECH key, or when an interceptor interfered with the exchange.
The CPU overhead isn't a problem from my POV. The problem is that the case where the wrong ECH was used is kinda like doing 1.5 handshakes. And as/if new ServerHello extensions come into play (esp PQC), or when we deal with old code interacting with but unrelated to ECH, or with custom- extension handling code that we'll never see, or with some other random change to the transcript, any of that might expose the brittleness of a 1.5 handshake design. As it happens, I've fixed the memory leaks this error case causes but its still messy - someone changing some unrelated bit of OpenSSL code in a year or two for some other reason could make my clean-up code break something in unpredictable ways. (Should my code end up upstream etc. etc.) So, quoting you out of order: > Look at the comment, "This change is definitely more > > invasive than the existing signal, but not all that hard to > implement. (E.g., cloudflare/go#38 <https://github.com > /cloudflare/go/pull/38>.)" later in the thread. I think the right thing here would be to analyse that attack again and re-evaluate which of the two answers now seems best. For me, the github issue discussion didn't leave behind enough information to do that. (Or I need to stare at it some more maybe:-) Cheers, S.
-- Christian Huitema
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
