I would like to see more discussion and work on DoS protection. I think many services are quite unprepared for massive DDoS attacks. Si vis pacem, para bellum.
>so burning CPU on a hash puzzle in those contexts is unappealing My understanding is that the server would only use the puzzle when it thinks it is under attacks, so I think the impact when not under attack is negliable. That said introducing I agree that something like this would take a long time. I agree that the best current defense is to swith to the fastest state-of-the art algorithms, which are x25519 and Ed25519. This becomes even more important i the future when most TLS connections will do hybrid ECH, and hybrid key exchange and maybe hybrid signing/verification in certs and CRL/OCSP. Regarding batch signatures ,I found the performance figures Nina Bindel presented in a NIST PQC Seminar interesting [1]. Cheers, John [1] https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/pqc-seminars/presentations/7-batch-me-if-you-pq-sign-07212023.pdf https://www.nist.gov/video/pqc-seminar-batch-me-if-you-pq-sign From: David Benjamin <david...@chromium.org> Date: Thursday, 31 October 2024 at 16:53 To: David Venhoek <da...@venhoek.nl> Cc: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: TLS client puzzles revival 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<mailto: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<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
