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

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 <martin.thomson@gmail.com> wrote:
> 
> On 14 May 2015 at 19:37, Watson Ladd <watsonbladd@gmail.com> wrote:
>> There does not appear to be
>> a cookie mechanism to mitigate this problem.
> 
> 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.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls