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

Vlad Krasnov <> Fri, 15 May 2015 20:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 93E091A1B79 for <>; Fri, 15 May 2015 13:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JcDCqCtC1_E4 for <>; Fri, 15 May 2015 13:09:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E35B11A1B2C for <>; Fri, 15 May 2015 13:09:25 -0700 (PDT)
Received: by wguv19 with SMTP id v19so63790654wgu.1 for <>; Fri, 15 May 2015 13:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DoBRfREVez9Tph0xPzjPj38F4NnOYBh4eRwyDQqzhOQ=; b=x6bIQXr1RjJBGoLFO8Th2wwBpKG1Gdg6EqwmcFI5eCYgRN5jv55UL+lm7mw7nAAvMY 1o9drbCCwepQ9PrLI7XFxcg8B83vrY/jQJo0BvFdzL4/PEnBen+R40Io1bDfypSXJmXP 0o/zXTR2ByiP6KXmHR40zveZMoWqMoXtNMw2A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=DoBRfREVez9Tph0xPzjPj38F4NnOYBh4eRwyDQqzhOQ=; b=iY04b5eEujbUtWOAP3UuD1S6MLdmydJPe9u1jW+E6q17aBE1ge7ng0sD48ai68w5UD Y8JocSDMJbvwbuP53Zsi/N+sJ65pIQsCefq0XjicNwF4M71rnzpDkFj2JhDfS523gbfX F7w5VP+09SvyNZesRr2LLMXV/JQO3nJ27XB44cIr/EBa5gGF3qgidecjcDPWOI+eEQaC MCldqcUttWbDT18eZGwTUtLnEJ8G57n1KiMWn/XUrCuNccgTghR0eEvJw85bVn5ad2JJ wsYH9IL7ReZqgKkf1ZDtVA972VZ3q24GfZoa3e4+Ai11C+7Lw/3q5RRtztcCZKFalvKV KSRw==
X-Gm-Message-State: ALoCoQm+MH0oihsYlW4rs0+UqInKHwV4YrqR3k+quDBxyZwdWUXI6BIwf13/bhZlwkRhASPWuiG/
X-Received: by with SMTP id o5mr22068263wjz.8.1431720564583; Fri, 15 May 2015 13:09:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id mc20sm4471171wic.15.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 May 2015 13:09:23 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Vlad Krasnov <>
In-Reply-To: <>
Date: Fri, 15 May 2015 21:09:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.2098)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] DoS risks from draft-vkrasnov-tls-jumpstart-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 May 2015 20:09:27 -0000

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 <> wrote:
> On 14 May 2015 at 19:37, Watson Ladd <> 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