> On 29 Jun 2016, at 10:25 PM, Brian Smith <br...@briansmith.org> wrote: > > Dmitry Khovratovich <khovratov...@gmail.com> wrote: >> It allows cheap and memoryless verification by the server even though the >> puzzle solving guaranteely requires dozens of MB of RAM from a client > > I feel like this is impractical simply because lots of people are > building HTTPS clients that don't even have dozens of MB of RAM total. > I think we should avoid doing anything that requires the client to > have more than ~16KB of memory total to devote to TLS stuff. > Otherwise, we force the internet to have an architecture where all > small devices require a smart proxy to solve these puzzles for them > and do other things.
Hi, Brian. Having clients commit resources to solve puzzles is always a balancing act between the capabilities of legitimate clients and those of the attackers. With CPU-intensive puzzles the attackers tend to be fast desktops and servers, while the legitimate clients could be as weak as a smart-object or as powerful as a server. It’s hard to find good parameters that will allow the oldest phone in while slowing the attacker down significantly. The same, as you pointed out, is true for RAM-intensive puzzles. For the web the legitimate clients fall into two categories: Desktops and laptops on the one hand, and mobile phones on the other. For CPU-intensive puzzles their capabilities are far apart, so you’d have to tune the puzzle to the capabilities of the weakest phone, or else accept that phones are cut off during a severe DDoS attack. With RAM, however, the differences are less pronounced. Both kinds of legitimate clients can afford to devote dozens of MB of RAM. The same is not true for IoT, but I’m talking about the real web here, not data services over HTTPS. I think for this particular case RAM-intensive puzzles make sense. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
