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

Erik Nygren <erik+ietf@nygren.org> Tue, 09 June 2015 23:25 UTC

Return-Path: <nygren@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBF61A8A4A for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 16:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhGu2qKiFIm3 for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 16:25:16 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F1B1A8A47 for <tls@ietf.org>; Tue, 9 Jun 2015 16:25:15 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so23721887igb.1 for <tls@ietf.org>; Tue, 09 Jun 2015 16:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HrAeof/otPMWPaknyZ/kg46Nuk9+BEJivIkHq8AbNlo=; b=Hz8VMHrEZ69Lr4jhewxHOw/adDMRzXhkeZbhGYeIBDz9OlsMhulbVyI/YpRSTvT49v FpcG4VtFGan+qA/KUAbnSa2o7VdBHuj43YD8Xp4N3riGieJKe6DcmReyuAXK6gjdUcgU bKa4+1nWd6Uubr8X3IXI88ppTKq2RkYKvaVTD5USDiQeBwwTUFoM7+flHwnr9mbTY4WC jaC3eW2HgG2aJq65vGqIBM8S/15cKDEiiYlaqJneQG3mCWDWMl7teNl9o+uqdStCsEYs uvGMM10rwIGJD/7bCfAzuYpu5+j9ANVk9RAY2KgPn+XtlCcpV6nV8RfS1zs7RRTk6o6T JhVQ==
MIME-Version: 1.0
X-Received: by 10.107.32.73 with SMTP id g70mr294182iog.23.1433892314210; Tue, 09 Jun 2015 16:25:14 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.79.35.193 with HTTP; Tue, 9 Jun 2015 16:25:14 -0700 (PDT)
In-Reply-To: <009101d0a1de$be9a76b0$3bcf6410$@alibaba-inc.com>
References: <----3-------MPf3-$0147073b-d557-427b-a8c7-d3dd80aef07b@alibaba-inc.com> <20150608093155.GA24860@LK-Perkele-VII> <009101d0a1de$be9a76b0$3bcf6410$@alibaba-inc.com>
Date: Tue, 9 Jun 2015 19:25:14 -0400
X-Google-Sender-Auth: ha9ydbEbe_IN45xDDSt9-PrkUY8
Message-ID: <CAKC-DJiV6rg+L2PZkCprqg+t_sWE951TOsVgtC9wP7_GrKePNQ@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
To: Bingzheng Wu <bingzheng.wbz@alibaba-inc.com>
Content-Type: multipart/alternative; boundary=001a1140407808e7f205181e1276
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sgKWyJyoYJpGblLBK0pHrBc-908>
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] add challenge in TLS v1.3 to prevent DDOS attack?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2015 23:25:18 -0000

We talked about this some at the TLS interim in Denver last year.
Yoav Nir even wrote up one variation:
https://tools.ietf.org/html/draft-nir-tls-puzzles-00
(and this idea even goes way back to
https://www.usenix.org/legacy/events/sec2001/full_papers/dean/dean.pdf
in 2001).  There was some desire to take an approach and try and get
it to look as close as possible to what DTLS is already doing with
HelloVerifyRequest
to try and reduce the number of different handshake flows.

The primary outcome of the discussion in Denver was a desire to understand
how a client puzzles scheme like this would help over simply doing
intelligent
server-side rate-limiting, especially as the two would likely need to be
used
together.  In cases where a small number of IPs are flooding in
connections,
server-side rate-limiting can be used to defend already today (although it
may
not differentiate between different users behind a CGNAT or proxy).
This then leaves more distributed attacks (eg, large bot nets with many
nodes)
in which case the challenge is to generate puzzles hard enough to slow down
the attackers while not stalling out mobile clients.  Giving the complexity
(and associated risks) involved in adding in this functionality, people
seemed
to want better models or simulations for what attacks it actually helped
with
vs other simpler approaches.

       Erik




On Mon, Jun 8, 2015 at 7:32 AM, Bingzheng Wu <bingzheng.wbz@alibaba-inc.com>;
wrote:

> 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.
>
> Thanks,
> Bingzheng
>
> > -----Original Message-----
> > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi]
> > 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:
> > https://www.ietf.org/mail-archive/web/tls/current/msg11763.html
> >
> >
> > -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>