Subject: Re: [TLS] TLS client puzzles

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2016 22:08:58 +0200

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 <[email-masked]> 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.
> 
> Cheers,
> Brian
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jul 2016 20:11:24 +0000

Do IoT devices generally talk to public-facing web servers?

---

From: Kyle Rose <[email-masked]>
Date: Wed, 6 Jul 2016 16:16:13 -0400

On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig <[email-masked]
> wrote:

> IoT devices. For many of those devices we are talking about 32 KB (in

I continue to feel like this is a valid objection to the wrong proposition.
I don't think the question is, "Should TLS client puzzles be issued by all
TLS servers under load?" but rather, "Would client puzzles be a useful
addition to the DDoS toolbox, and appropriate in some cases?"

Kyle

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 6 Jul 2016 13:16:15 -0700

> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2016 22:19:57 +0200

> 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 cloud
infrastructure to upload sensor data and to wait for commands. This
communication would be secured using TLS.

You can even play around with such services, if you have spare time. IBM
(with Bluemix), Microsoft (with Azure for IoT), ARM (with mbed), and
many others are offering such functionality.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2016 22:23:23 +0200

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 difficulty and what is a piece of cake for a desktop
computer kills the battery of an IoT device.

(And note that I am not saying that IoT devices aren't used for DDoS
attacks.)

On 07/06/2016 10:16 PM, Kyle Rose wrote:
> On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I continue to feel like this is a valid objection to the wrong
> proposition. I don't think the question is, "Should TLS client puzzles
> be issued by all TLS servers under load?" but rather, "Would client
> puzzles be a useful addition to the DDoS toolbox, and appropriate in
> some cases?"
> 
> Kyle
>

---

From: Kyle Rose <[email-masked]>
Date: Wed, 6 Jul 2016 16:34:37 -0400

On Wed, Jul 6, 2016 at 4:23 PM, Hannes Tschofenig <[email-masked]

> (And note that I am not saying that IoT devices aren't used for DDoS

The point I was making earlier was simply that many web properties have
client population profiles that are overwhelmingly web browsers, and others
that are overwhelmingly IoT devices: client puzzles might be helpful on the
former, and useless on the latter. Objections that "IoT devices can't
handle client puzzles" doesn't apply to web properties with a web browser
client profile: it's like arguing that liver tastes bad when presented with
strawberry shortcake: yeah, that might be true... but it's not relevant.

Kyle

---

From: Dave Garrett <[email-masked]>
Date: Wed, 6 Jul 2016 20:33:19 -0400

> (And note that I am not saying that IoT devices aren't used for DDoS

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 access and no updates and distributed widely would be an even greater PITA to deal with than we've had in the past. IoT being currently incapable of attempting to use this system almost feels like a feature, rather than a bug.

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 Jul 2016 00:45:19 +0000

>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, incidentally, is one of the reasons why I'm pushing for TLS-LTS.
There's a huge, and growing, amount of embedded stuff out there that needs a
long-term stable protocol that can be baked into it to talk to its C&C servers
securely.  Some of the alternatives that are being dreamed up are... scary.
They make WEP look good).

Peter.

---

From: Bill Cox <[email-masked]>
Date: Thu, 7 Jul 2016 10:08:02 -0700

On Wed, Jul 6, 2016 at 1:16 PM, Kyle Rose <[email-masked]> wrote:

> On Wed, Jul 6, 2016 at 4:08 PM, Hannes Tschofenig <
> [email-masked]> wrote:
>
> proposition. I don't think the question is, "Should TLS client puzzles be
> issued by all TLS servers under load?" but rather, "Would client puzzles be
> a useful addition to the DDoS toolbox, and appropriate in some cases?"
>
> Kyle
>

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.

The most similar effort I know of is one I work on: token binding.  Rather
than bake it into TLS, we're using the custom extension API.  If there were
a separate effort to standardize client puzzles, similar to what we are
doing with token binding, I would be interested in participating.

Bill

---

From: Kyle Rose <[email-masked]>
Date: Thu, 7 Jul 2016 17:36:58 -0400

> at the higher levels above TLS, or possibly as a custom extension that does

A custom extension is a promising approach: this is what Erik Nygren
proposed in nygren-tls-client-puzzles-00 following discussions with some
IETF folks and Akamai colleagues. That draft has expired and doesn't
reference any of the recent work on memory-hard puzzles, but it might be a
good starting point.

Except at the pre-TLS stage for applications that use STARTTLS-style
mechanisms, I'm not sure how this could work at levels above TLS: the
primary attack targeted by client puzzles would be a client doing almost no
work in order to force the server to do expensive crypto, which means it
must be engaged prior to the handshake.

Kyle

---

From: Erik Nygren <[email-masked]>
Date: Fri, 8 Jul 2016 14:58:12 -0400

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
machine
or protocol itself.  (Clients indicate support via an extension, and then
puzzles
are challenged with a HelloRetryRequest extension, and then the ClientHello
retry
contains the updated extension.)

Note that the -01 version still needs some updates to match up to more
recent TLS 1.3 drafts.  (Some of the specifics may be a little out-of-date
and will be updated in the next revision.)

      Erik

On Thu, Jul 7, 2016 at 5:36 PM, Kyle Rose <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>