I'm not very excited about this DoS approach. Many user-facing clients run on battery-constrained devices, so burning CPU on a hash puzzle in those contexts is unappealing. Before we resort to mitigating a server's high energy cost by increasing energy cost across the board, we should exhaust avenues for decreasing the energy cost across the board. In particular...
I don't think the 10x figure for RSA certificates matters here. Any approach with a new extension, like client puzzles, will only be available in newer clients. This means, as a baseline, you're already assuming the server can reduce service to older clients that don't support the extension. (Or deny service if all supported clients have it.) Rather than ask clients to implement this extension, you could instead ask newer clients to support ECC-based server certificates[*], and then reduce or deny service to older RSA-requiring clients instead. Client puzzle's DoS capacity is only meaningful when you're already using more efficient server credentials. If, even with ECC-based server certificates, DoS is a concern, I would suggest reviving draft-ietf-tls-batch-signing instead. That was adopted by the WG, but it was parked because interest (including from my end) waned. But I would be much more interested in building that than in building an extension whose sole purpose is to burn CPU. Batch signing means the cost of the server signature is basically irrelevant. If you get a storm of requests from batch-capable clients, they all can be serviced with a single signature. Even if you only have the capacity to globally generate one signature at a time, you can still batch together all your incoming connections to be serviced by that one batch. David [*] Of course, if you are a hosting provider whose customers provide keys and certificates, they might not have provided an ECC credential. But, in that scenario, encouraging ECC credential from your customers is a much more impactful DoS capacity win because ECC-capable clients are already widely deployed. On Thu, Oct 31, 2024 at 10:14 AM David Venhoek <da...@venhoek.nl> wrote: > Dear TLS working group, > > Given recent experiences by some parties of DDoS attacks that abuse > the TLS handshake to force a server into spending significant > computational resources (see Eirik Øverby's talk at > https://www.youtube.com/watch?v=pBNMWvfL05g for an example), we have > decided to give adding handshake DDoS protections another go. The > draft is available at > https://github.com/tweedegolf/draft-TLS-client-puzzles already and we > will be submitting it to the IETF datatracker shortly. > > In the interest of giving this effort a better shot at success, we are > currently also working on implementing this proposal for a number of > major TLS implementations, including OpenSSL and BoringSSL. We already > have a near-complete implementation for RusTLS, and a working patched > version of Chromium. We will have these available as a demo during the > hackathon, where we will also be putting in some work to get more > implementations working (project TLS Client puzzles: > https://wiki.ietf.org/en/meeting/121/hackathon#tls-client-puzzles). If > you are in any way interested in this please come say hi. > > Motivation for this work is that implementing this draft has, based on > preliminary measurements on nginx, the ability to provide at least a > 4x increase in capacity to withstand attacks when using Ed25519 > certificates (and a factor 10x for RSA certificates). Furthermore, the > draft is written to allow for a custom TLS implementation that can > handle the generation and checking of puzzles in a different security > domain. So it is possible to create a third party service that parties > can use to mitigate DDoS attacks without having to provide that third > party with full unencrypted access to all traffic. > > This last point is also why we feel it is important to pursue this > work. Although right now it is possible to mitigate DDoS attacks by > paying a large cloud provider to handle TLS termination, this requires > the cloud provider to handle the unencrypted data. From a privacy > perspective, this is not always desirable, and in some industries > (such as finance and perhaps healthcare) might not even be allowed > because of compliance rules. > > Our aim is not to make these attacks entirely impossible, but rather > to allow the defender to raise the cost for the attacker. Especially > financially motivated attacks can be significantly deterred by this. > This is also what motivates us to use hash functions like SHA2, > prioritizing a low cost for the server to check puzzles rather than > maximizing difficulty for attackers. This ease of checking together > with the ability to offload the server side of handling the puzzles > should avoid the problem of the puzzles themselves becoming an attack > vector. > > Kind regards, > David Venhoek > Wouter Bokslag > Marc Schoolderman > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
