On Wed, Jun 29, 2016 at 3: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. > I think the appropriateness of client puzzles depends on what sorts of tradeoffs we're willing to accept. Let's say we have a DoS attacker profile that is not distinguishable from legitimate traffic, since that's the hard case. Do we want to be able to serve *some* traffic during a DoS attack? If we can't distinguish between legitimate users and attack traffic, we have to assume everyone's a potential attacker. It seems what we're left with is either rationing client requests or raising the cost of requests. Rationing can be sliced up in any number of ways, but effectively amounts to randomly denying some percentage of legitimate requests because we're assuming attack traffic and legitimate traffic have the same profile. (In reality, outside of NAT scenarios, we may be able to give immediate service to existing clients and ration new clients; but we're assuming the horse is a sphere for the sake of argument.) Raising the cost of requests has a similar problem in that you're punishing every client, but in doing so you do allow all clients capable of absorbing the increased cost (e.g., memory, computing power) to get access to the resources they need if the user is willing to accept that cost (e.g., energy, latency). The problem you pointed out is that of clients that aren't capable of absorbing the increased cost, such as low-power or memory-constrained embedded devices. This is a legitimate concern, but I don't think it universally disqualifies client puzzles. Maybe memory-hard puzzles aren't appropriate for services that talk to IoT devices, but that doesn't mean they aren't appropriate for websites that serve primarily to browsers. To benefit from client puzzles on their websites, providers running IoT REST services on the same server running their website may want to reconsider that arrangement. Any client puzzle proposal must of course allow the server to choose whether and when to issue a client puzzle, which in the absence of authenticated client identity information should probably be based on the expected client profile. Tl;dr: memory-hard client puzzles are not universally appropriate as a DoS defense, but I don't think that means they are never appropriate. Kyle
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
