Hi All, Thanks for the feedback. Just to clarify a few points, yes this would be intended as a last resort solution. We think the negative impact on interactive clients (and in particular, browsers) can be mitigated in large part by asking user permission before spending compute. That would probably also make servers hesitant to overuse the puzzles. In the end, the goal is that the mere presence of this option makes dos attacks against the handshake in particular economically uninteresting, such that the mere presence of a mitigation mechanism means we hopefully almost never need it.
Thanks also for the suggestions for alternate solutions to try now. We are in discussions with the attacked party to see if we can try those out now, to see what impact they will have. The long lead time before this would be usable "in the wild" for us would be exactly the reason to move forward with this now. By its very nature, a solution like this needs long lead times, so waiting until we see large scale concrete attacks that we cant immediately mitigate other ways is going to mean a very painful decade for anyone in the crosshairs of attackers. Especially with the coming transition to post-quantum cryptography, this scares me a little, as these might change the (d)dos attack picture in unexpected ways and (as far as I am aware) we have little in the way of formal methods to prove there are no (d)dos-able vulnerabilities in the handshake. Thank you Bas for the concrete numbers, and for the perspective of comparing bandwidth in vs compute. We are planning to do some modelling in the coming months to better understand the impact and how the client puzzles can and cannot mitigate the problems. We will come back once we have some concrete numbers and models to share on that. Kind regards, David Venhoek On Fri, Nov 1, 2024 at 2:55 PM Joseph Birr-Pixton <jpix...@gmail.com> wrote: > > On Fri, 1 Nov 2024 at 11:50, Bas Westerbaan > <bas=40cloudflare....@dmarc.ietf.org> wrote: >> >> Here we're not accounting for the new bottleneck on server upload which >> these post-quantum signatures add. But that's a bandwidth issue — not a >> compute one. > > > On top of that, the HRR/ClientHello Cookie extension already in TLS1.3 can > also provide this kind of effect: the server can require the client to echo > up to 16KB of data in its retry. This means an equivalent to the "Echo Client > Puzzle Type" in this draft is already deployable today. > > Cheers, > Joe _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
