Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack?

"Bingzheng Wu" <> Mon, 08 June 2015 11:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DECF1A1BCF for <>; Mon, 8 Jun 2015 04:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LbW0RXiB7L9B for <>; Mon, 8 Jun 2015 04:32:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F8FB1A1BCD for <>; Mon, 8 Jun 2015 04:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1433763128; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=ge57TBFSwwHRg20YJtWmGxmW8e6BKkl2B5qNSKLaFzU=; b=msA3ifMc5UIM7px+g8YhAYqaiFy53N3/Mnv00HVjcz1bUdMa/RgVwlWXWZUkMxq4K/nf9aHmgZOccZnOx3PtBYs6XfN69mGWboO1PlL0Y76Hx1ni3kYkBdMyJWqn7/57kCMeXfWU0EBdGQgnHBVNCagVNmuifOmtzZQTZDU8an4=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R761e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03024;; PH=DS; RN=2; RT=2; SR=0;
Received: from ali074145n( ip: by; Mon, 08 Jun 2015 19:32:04 +0800
From: "Bingzheng Wu" <>
To: "'Ilari Liusvaara'" <>
References: <----3-------MPf3-$> <20150608093155.GA24860@LK-Perkele-VII>
In-Reply-To: <20150608093155.GA24860@LK-Perkele-VII>
Date: Mon, 08 Jun 2015 19:32:04 +0800
Message-ID: <009101d0a1de$be9a76b0$3bcf6410$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJM1bQwrAdL2mUOwfD9yh9pSzi+dQGfXzEVnJ0QkBA=
Content-Language: zh-cn
Archived-At: <>
Cc: 'tls' <>
Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack?
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bingzheng Wu <>
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: Mon, 08 Jun 2015 11:32:16 -0000

I am sorry that I did not search the list archive thoroughly.
The scheme in your link is what I wanted (and the hash-challenge is better than my propose).

But I have one question still. It's said that this scheme can be implemented as an extension.
If a client who dose not support this extension receives the challenge, what should it do?
Just abort the connection?
Then some servers who provide important services may dare not to enable this scheme, to avoid impacting the users who use TLS client not supporting this extension.

Please fix me if I misunderstand that propose.


> -----Original Message-----
> From: Ilari Liusvaara []
> Sent: Monday, June 08, 2015 5:32 PM
> To: Bingzheng Wu
> Cc: tls
> Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack?
> On Mon, Jun 08, 2015 at 04:46:18PM +0800, Bingzheng Wu wrote:
> > Hi all,
> >
> > TLS is susceptible to DDOS attack.
> > In TLS v1.3, attackers can generate ClientHello and ClientKeyshare
> > messages easily, while the server has to consume large amounts of CPU
> > doing asymmetric crypto operations to generate ServerKeyshare and
> > ServerCertificateVerify messages.
> Note that this type of attack already works in TLS 1.2.
> > So, could we add a challenge-response mode in TLS v1.3 to increase the
> > attacker's cost ?
> There is already an issue about this (but given nature of that issue, it should be
> discussed on this ML, especially as it still seems to be open).
> > The mode is disable in usual.
> > If the server think it's under attack (e.g. >1000 qps), it could
> > enable this mode by responding a HelloRetryRequest (or a new type)
> > message to the client with a challenge.
> > The client receiving the challenge must solve the challenge which is
> > expensive in CPU, and continue the handshake by carrying the
> > challenge's answer.
> One has to be careful that this kind of thing doesn't introduce security issues.
> E.g. Proper implementations can not restart handshake, and repeating yourself
> is legendary source of bugs.
> > For example, server could make the challenge by encrypting an random
> > number by a RSA public key (which is short), and send the private key
> > (which is long) and cipher text to client.
> The usual way things like this are done is via hashes.
> TLS13 github issue #9 has link to a ML post describing one scheme:
> -Ilari