Re: [TLS] TLS client puzzles

Erik Nygren <> Fri, 08 July 2016 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B15DA12D620 for <>; Fri, 8 Jul 2016 11:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nasSmLWFVwz9 for <>; Fri, 8 Jul 2016 11:58:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B49312D0AF for <>; Fri, 8 Jul 2016 11:58:14 -0700 (PDT)
Received: by with SMTP id u186so16279531ita.0 for <>; Fri, 08 Jul 2016 11:58:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eKzIfiWg+yPwrshneUlRDGotntXnGFfSDv9HvCpVFGM=; b=IgB9ECrUG2/vRmTZVABNXr+80egix5OAPP+ONCjegPUXAnoty7ulU2PqmE+6DNBKiz Q2a3a9nCf0AbI31boC/jbIAmXjlgyFBxdZ8zP12tuAtXUjlegppUD8eSX0BlaFkbNQ4R dWBggz01O7K/V3wiiJ/7tq/siXO98QKy85VyIrbDQJ1Qjm5XOM08vjwP2aALXWGRrtpd eP8Gqak9Jp5AjZEsWfUZUBlElBjOeaCT7U9P4YtVze7w0n6LA6CPIZPDP4XeYlr9qLzD r/ikkZdt/9R88WdKD+frEIM2iEVaIjrB5wjOFhMRG5179JRGOtpG3Qu8WmMBqiEQThZk 4DxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eKzIfiWg+yPwrshneUlRDGotntXnGFfSDv9HvCpVFGM=; b=Bf1gjfVMg33r7d0cXeJNBD6BqDqJPskEcIoK/sVvJjimcK4ZZTkiolAeyLVQaC8p+4 DOb+VWiWuZZujHlao9QPI0EolhCe6OLhcvGZIz1ZPsk2N1PhxCRQDmmLa7sKPiLigdhx RRo2qiU+ZAk1yTMMwgKLWBIIVPfC7pZsnUUvBhgurECGsvjp879N4VDIRTO6CWUa52ZK JnyD9IDpTkZ9YH3iy7yu1Z+EyZAR/K2swoqaY0wnDGUBloN3/XP9EkbtYGq8JCAt6HIL h4iK37HuJt6hthLtlHZCvTSIB6ydpwpZTIGnNBER/5/Pn4bzk9c0FMLD1Zzv5gMNRiwr wMQA==
X-Gm-Message-State: ALyK8tJIsEgMd5Ufu69gfmIk9inQHLIYzINYXgBL2Pu4N701v7U27wYARLqAaWms1KbB3AD+e82GPyztRvFqbw==
X-Received: by with SMTP id s206mr4974232itd.82.1468004293666; Fri, 08 Jul 2016 11:58:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Jul 2016 11:58:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Erik Nygren <>
Date: Fri, 08 Jul 2016 14:58:12 -0400
X-Google-Sender-Auth: --gy7yqhgK72t3ICsvaSF5rolJQ
Message-ID: <>
To: Kyle Rose <>
Content-Type: multipart/alternative; boundary="94eb2c05e6ec73ed3c05372462ba"
Archived-At: <>
Cc: Dmitry Khovratovich <>, "<>" <>
Subject: Re: [TLS] TLS client puzzles
X-Mailman-Version: 2.1.17
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, 08 Jul 2016 18:58:17 -0000

This is also what is still proposed in the -01 version at the top of this

By leveraging the HelloRetryRequest in TLS 1.3, it provides client puzzles
as an extension mechanism to TLS without requiring changes to the state
or protocol itself.  (Clients indicate support via an extension, and then
are challenged with a HelloRetryRequest extension, and then the ClientHello
contains the updated extension.)

Note that the -01 version still needs some updates to match up to more
recent TLS 1.3 drafts.  (Some of the specifics may be a little out-of-date
and will be updated in the next revision.)


On Thu, Jul 7, 2016 at 5:36 PM, Kyle Rose <> wrote:

> I agree, and I think it is clear that client puzzles can be a useful
>> addition to the DDoS defense toolbox.  However, most of this can be handled
>> at the higher levels above TLS, or possibly as a custom extension that does
>> not complicate TLS.
> A custom extension is a promising approach: this is what Erik Nygren
> proposed in nygren-tls-client-puzzles-00 following discussions with some
> IETF folks and Akamai colleagues. That draft has expired and doesn't
> reference any of the recent work on memory-hard puzzles, but it might be a
> good starting point.
> Except at the pre-TLS stage for applications that use STARTTLS-style
> mechanisms, I'm not sure how this could work at levels above TLS: the
> primary attack targeted by client puzzles would be a client doing almost no
> work in order to force the server to do expensive crypto, which means it
> must be engaged prior to the handshake.
> Kyle
> _______________________________________________
> TLS mailing list