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
