This is a bit of a tangent, but PQC seems to have the opposite effect of what you might think if you use fast implementations.
A typical ClientHello with X25519 is, say, about 350 bytes. A modern Intel core can do about 20,000 X25519 keyshare and P-256 sign together per second. That's 56 Mbit/s. Thus you need at least 18 cores per gigabit/s of ClientHello. ML-KEM-768 encapsulation is vast: around 50,000/s per core. If we add that on top of X25519, we can process about 14,000 ClientHello's. Those are bigger at 1534 bytes. Thus we process hybrid ClientHello's at 171Mbit/s. Thus you need about 6 cores per gigabit/s of ClientHello. Now, adding post-quantum signatures will depress that number again. It depends on which we'll end up using. With ML-DSA-44 it'll still be higher than 73 Mbit/s. 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. Best, Bas On Fri, Nov 1, 2024 at 9:27 AM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> wrote: > 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> 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
