Re: [TLS] TLS client puzzles

2016-07-08 Thread Erik Nygren
This is also what is still proposed in the -01 version at the top of this thread: https://tools.ietf.org/html/draft-nygren-tls-client-puzzles-01 By leveraging the HelloRetryRequest in TLS 1.3, it provides client puzzles as an extension mechanism to TLS without requiring changes to the state m

Re: [TLS] TLS client puzzles

2016-07-07 Thread Kyle Rose
> I agree, and I think it is clear that client puzzles can be a useful > addition to the DDoS defense toolbox. However, most of this can be handled > at the higher levels above TLS, or possibly as a custom extension that does > not complicate TLS. > A custom extension is a promising approach: thi

Re: [TLS] TLS client puzzles

2016-07-06 Thread Peter Gutmann
Salz, Rich writes: >Do IoT devices generally talk to public-facing web servers? Yes, in large quantities. Public web servers are often the only channel they have to the outside world (apart from direct access on the LAN segment they're on, but that's often only for admin stuff). (This, inciden

Re: [TLS] TLS client puzzles

2016-07-06 Thread Dave Garrett
On Wednesday, July 06, 2016 04:23:23 pm Hannes Tschofenig wrote: > (And note that I am not saying that IoT devices aren't used for DDoS > attacks.) For that matter, I feel like IoT is a larger DDoS risk in the long-term than other arenas. A botnet of bazillions of little widgets with Internet acc

Re: [TLS] TLS client puzzles

2016-07-06 Thread Kyle Rose
On Wed, Jul 6, 2016 at 4:23 PM, Hannes Tschofenig wrote: > the question for me is whether it will be an effective mechanism when > many devices just do not support it (for a number of reasons)? For IoT > devices the reason is simple: they don't have MBs of memory. > > Even the regular puzzle tech

Re: [TLS] TLS client puzzles

2016-07-06 Thread Hannes Tschofenig
Kyle, the question for me is whether it will be an effective mechanism when many devices just do not support it (for a number of reasons)? For IoT devices the reason is simple: they don't have MBs of memory. Even the regular puzzle technique has the problem that you have to adjust the puzzle diff

Re: [TLS] TLS client puzzles

2016-07-06 Thread Hannes Tschofenig
On 07/06/2016 10:11 PM, Salz, Rich wrote: > Do IoT devices generally talk to public-facing web servers? There are different deployment scenarios, as outlined in this ISOC publication: http://www.internetsociety.org/doc/iot-overview In one frequent deployment model the IoT device connects to the

Re: [TLS] TLS client puzzles

2016-07-06 Thread Kyle Rose
On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig wrote: > I agree with Brian here on this issue. This is clearly impractical for > IoT devices. For many of those devices we are talking about 32 KB (in > total). I continue to feel like this is a valid objection to the wrong proposition. I don't

Re: [TLS] TLS client puzzles

2016-07-06 Thread Tony Arcieri
On Wednesday, July 6, 2016, Salz, Rich wrote: > Do IoT devices generally talk to public-facing web servers? > Yes, I'd consider that part of the "Internet" aspect of "Internet of Things" -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www

Re: [TLS] TLS client puzzles

2016-07-06 Thread Salz, Rich
Do IoT devices generally talk to public-facing web servers? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS client puzzles

2016-07-06 Thread Hannes Tschofenig
I agree with Brian here on this issue. This is clearly impractical for IoT devices. For many of those devices we are talking about 32 KB (in total). On 06/29/2016 09:25 PM, Brian Smith wrote: > Dmitry Khovratovich wrote: >> It allows cheap and memoryless verification by the server even though the

Re: [TLS] TLS client puzzles

2016-06-30 Thread David Adrian
On Wed, Jun 29, 2016 at 12:25 PM Brian Smith wrote: > Dmitry Khovratovich 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 peop

Re: [TLS] TLS client puzzles

2016-06-30 Thread Yoav Nir
> On 29 Jun 2016, at 10:25 PM, Brian Smith wrote: > > Dmitry Khovratovich 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 peop

Re: [TLS] TLS client puzzles

2016-06-29 Thread Valery Smyslov
Hi, you may be also interested in similar work done in ipsecme group: https://www.ietf.org/id/draft-ietf-ipsecme-ddos-protection-06.txt The draft describes various defnse methods against (D)DoS attacks in IKEv2 and, in particular, introduces puzzles. We tried to specify using puzzles in such a w

Re: [TLS] TLS client puzzles

2016-06-29 Thread Christian Huitema
On Wednesday, June 29, 2016 7:37 PM, Geoffrey Keating wrote: > > Kyle Rose writes: > > > Let's finish that last sentence: > > > > I have to think a lot more about the IoT/resource-constrained client > > problem, but I still don't think the existence of clients that would be > > denied service by

Re: [TLS] TLS client puzzles

2016-06-29 Thread Geoffrey Keating
Kyle Rose writes: > Let's finish that last sentence: > > I have to think a lot more about the IoT/resource-constrained client > problem, but I still don't think the existence of clients that would be > denied service by this scheme renders the concept completely inapplicable. Perhaps for the re

Re: [TLS] TLS client puzzles

2016-06-29 Thread Kyle Rose
Let's finish that last sentence: I have to think a lot more about the IoT/resource-constrained client problem, but I still don't think the existence of clients that would be denied service by this scheme renders the concept completely inapplicable. ___ T

Re: [TLS] TLS client puzzles

2016-06-29 Thread Kyle Rose
On Wed, Jun 29, 2016 at 5:41 PM, Christian Huitema wrote: > On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote: > > > > 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 increas

Re: [TLS] TLS client puzzles

2016-06-29 Thread Christian Huitema
On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote: > > 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 > resource

Re: [TLS] TLS client puzzles

2016-06-29 Thread Kyle Rose
On Wed, Jun 29, 2016 at 3:25 PM, Brian Smith wrote: > Dmitry Khovratovich 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 peop

Re: [TLS] TLS client puzzles

2016-06-29 Thread Brian Smith
Dmitry Khovratovich 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

[TLS] TLS client puzzles

2016-06-29 Thread Dmitry Khovratovich
Dear all, together with our colleagues from Akamai, we would like to pursue further the draft on the TLS client puzzles, the first version of which was aired in 2015. As before, the client puzzles allow a server to request clients perform a selected amount of computation prior to the server perfor