I fully agree. In addition to that wide enough adoption of any mandatory changes to TLS handshake will take years and any public facing services will have to allow clients that do not support puzzles for backwards compatibility for quite some time.
On top of low-powered battery operated clients there are also proxies and NGFWs that can already run at a high utilization and additional spiky computation requirements will require both software and hardware upgrades. Finally, the key problem outlined in this draft: "Once an attacker has opened a TCP connection, the attacker can transmit effectively static content that causes the server to perform expensive cryptographic operations." can be mitigated with regular HRR just asking for a keyshare with a different (but still cryptographically acceptable) curve. Botnet that is spamming a server with a static ClientHello will not be able to correctly respond to HRR. I think a data-driven best practices overview of application layer DoS/DDoS against TLS 1.3 and corresponding mitigation techniques would be a good start before diving deep into new computationally expensive solutions. Best Regards, Yaroslav On Thu, Oct 31, 2024 at 3:52 PM David Benjamin <david...@chromium.org> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
