Subject: [TLS] DoS risks from draft-vkrasnov-tls-jumpstart-00

From: Watson Ladd <[email-masked]>
Date: Thu, 14 May 2015 19:37:58 -0700

Dear all,

I'd like to explain some of the ways in which
draft-vkrasnov-tls-jumpstart may provide opportunity for mischief. The
first, and most obvious, is that responses are considerably larger
than requests, leading to amplification. The second is that each
request creates state that is supposed to be stored on the server,
leading to exhaustion of server resources. There does not appear to be
a cookie mechanism to mitigate this problem.

For resumed connections these problems are much less serious. It may
be that resumption only is a better fit for this approach to latency
reduction.

Sincerely,
Watson Ladd

---

From: Vlad Krasnov <[email-masked]>
Date: Fri, 15 May 2015 07:21:56 +0100

Hi,

For the first part - that is a regular amplification attack, which in that case has lower amplification factor than many other existing UDP protocols. 
I also address this in "Security considerations” chapter, where I propose a general technique to mitigate attacks of such type, that may apply to other UDP protocols as well.
For the second - the server chooses how much history to keep, and the timeout period for initiated handshakes. If the history is full, it will start ignoring incoming ClientHellos.

Under normal operation a typical serve can handle all incoming connections. Under attack it can easily fallback to legacy operation. 

Thanks,
Vlad

> On 15 May 2015, at 03:37, Watson Ladd <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 May 2015 10:42:32 -0700

On 14 May 2015 at 19:37, Watson Ladd <[email-masked]> wrote:
> There does not appear to be

You are absolutely right about this.  DTLS does offer a mechanism like
this, and it seems likely that it will become part of TLS 1.3, but
attempting to retrofit a performance optimization onto TLS 1.2 without
that sort of basic DoS mitigation seems unwise.  Maybe DTLS 1.3 will
use the padding extension to avoid the amplification attack too.

One advantage of the cookie mechanism is that it is optional.  You can
get the performance benefits when the server isn't stressed and still
have a fallback in case of high load.

---

From: Vlad Krasnov <[email-masked]>
Date: Fri, 15 May 2015 21:09:21 +0100

The cookie mechanism is good, but misses the point of this protocol.

First of all, cookie generation and validation by itself is not a computationally free operation. More importantly requesting a cookie takes a round that we are trying to save.

On the other hand a modest 8-core Haswell based server, can perform well over 300,000 ECDSA+ECDHE ServerHellos per second, that means that a 10GBit card would be overwhelmed by the incoming ClientHello before the CPU is.  Non forward secrecy handshakes do not require any real computation on the ServerHello.

But the server should not get to the point of taking so many requests. The idea is that if the server suspects something or is under any kind of attack or even without any reason at all, does not have to respond over UDP, and nothing bad happens, the connection continues as usual over TCP without a hiccup.

A normal server would keep a state for say 10,000 - 20,000 handshakes per second (less than 1MB of data with ECDHE, and well below modern processor capabilities), and refuse to accept more than that. Of course larger servers will decide how much they are willing to accept. That means that while the extension itself can be DoSed, but the legacy connection will take place as usual over TCP and the client wouldn’t know. You don’t need a cookie for that at all.

The padding can take care of an amplification attack, although the amplification for a typical certificate chain, is less than 10x. And a server shall not respond to a client more than once for a given period of time via UDP. I think that makes the protocol very resilient to regular amplification attacks, especially compared to protocols like DNS or SSDP.

Most of the time servers are not flooded, and therefore most of the time connections will be accelerated significantly.

> On 15 May 2015, at 18:42, Martin Thomson <[email-masked]> wrote:
>