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

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
>