Re: [TLS] TLS client puzzles

"Valery Smyslov" <> Thu, 30 June 2016 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 101F712D5CE for <>; Wed, 29 Jun 2016 23:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.929
X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 JG6GR6nKBYpf for <>; Wed, 29 Jun 2016 23:37:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5822512D5E8 for <>; Wed, 29 Jun 2016 23:37:56 -0700 (PDT)
Received: by with SMTP id l188so48327738lfe.2 for <>; Wed, 29 Jun 2016 23:37:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version; bh=cnDwhdoRQVjOBGkH9HnG/4fBcijgL6qjEzxJZKZAx7k=; b=S6PQ1EKVXLEWtFkvlHVyNpvG0c0upXwE9EajxZlpva85dnWHkRv/63nMtPyAGv5EPm w6Njc1I+6JXm9LHZnawjRmBxL3TsRexVnw/bqy6Lv3/6xOM89xm1NxdHzfzmPd2yS432 q7wrG3u990R2AYPrIJo5FiPiyK8EO32QJ5x/zgxOF2rzRn73kRWbgwe5fkO7o+jj+D5n DJsNBGQmCX5Q8cEK3KBpMUiMNJqMGkIQd3O+4g31JQjUlxcUl0F4hYvy2yeKe+bZ0Jlf piIT29+CkyBHMiskkP9T147pm56M2DASuK1ZgVBjwdYfXwakMm6KylBzn5MacE/uUohh aP4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version; bh=cnDwhdoRQVjOBGkH9HnG/4fBcijgL6qjEzxJZKZAx7k=; b=my/kDQJ5emsojFXbNUkpn1wop4WYg5i1RD/q03fThrjkqhGbL3kscr6c/ItEMcywuR MV9I9fxUHraFCJqctgoJwKQQqueu7Yb4sZp0sx6TWRQETKaV6KgWlqDYcd3/BtuCOTrs wCwF5pmqR5o95tBErqFQoTNIaeKiP2eyCyhJKigWciyVLF4XjDKrBYx0MOsNtn3VGwub T84xMarTQiTVdbhCDoAxkFbopAr0gs2xZwCS0q6muW+vT7q+CWYTF6V9HUrwKujbwpaB iX5VMVJANF4STHueHU6SDVxlE7OzaZhDUueqfhVzqbjpx77MfCAfomo1y2Wj0fBe/hsa 62cQ==
X-Gm-Message-State: ALyK8tKODAHSxhMMHqdZToS9JbUpmUTa3YZ6BToMdVzwS1zpHXPxSPWS5f+9Vea6m+OQrw==
X-Received: by with SMTP id 16mr3849903lja.56.1467268674546; Wed, 29 Jun 2016 23:37:54 -0700 (PDT)
Received: from buildpc ([]) by with ESMTPSA id 76sm1275841lfu.26.2016. (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 29 Jun 2016 23:37:53 -0700 (PDT)
Message-ID: <A1D3BF0AC24D4ECF92ED60A59AA3160D@buildpc>
From: Valery Smyslov <>
To: Kyle Rose <>, Christian Huitema <>
References: <> <> <> <> <>
Date: Thu, 30 Jun 2016 09:37:52 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_190A_01D1D2B3.12BEAD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
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: Thu, 30 Jun 2016 06:37:59 -0000


you may be also interested in similar work done in ipsecme group:

The draft describes various defnse methods against (D)DoS attacks in IKEv2
and, in particular, introduces puzzles. We tried to specify using puzzles
in such a way that their negative impact on legitimate (or even unsupporting) initiators
be as small as possible (although of course it cannot be completely avoided).
The draft is in WGLC now.

Valery Smyslov.

  On Wed, Jun 29, 2016 at 5:41 PM, Christian Huitema <> wrote:

    On Wednesday, June 29, 2016 2:08 PM, Kyle Rose wrote:
    > Raising the cost of requests has a similar problem in that you're punishing
    > every client, but in doing so you do allow all clients capable of absorbing
    > the increased cost (e.g., memory, computing power) to get access to the
    > resources they need if the user is willing to accept that cost (e.g., energy,
    > latency).

    The obvious issue with the "proof of work" defense against DDOS is that the bot nets can do more work than many legitimate clients. The puzzle approach will cut off the least capable legitimate clients, such as old phones or IOT devices. It will not cut off the PC enrolled in a bot net. It will merely slow it down a little. But then, you could have the same effect by just delaying the response and enforcing one connection per client.

  I agree with you that the above seems equivalent in theory, but in practice it might not be feasible.

  The biggest obstacle seems to be enforcing one connection per client. Let's say rate limiting on a per-client basis doesn't work because many of your clients are behind a NAT; or because the attacker is using IPv6 and generates a ton of temporary addresses that make the situation indistinguishable from many legitimate clients in the same subnet. So you can either serve one (or a small N) of them at a time, or you drop that restriction and allow a single client to mount an asymmetric attack.

  Alternatively, what if you have lots of geographically-distributed servers and can't share client rate limiting state among them quickly enough to detect and blacklist attackers?

  It's possible there are additional asymmetric attack vectors I'm not thinking of, which is why I like this as a general defense against a class of attacks. I mostly agree it's mostly worthless when you have one server facing a botnet of 100,000 machines, but frankly that one server is a sitting duck regardless of countermeasures. OTOH, what if you have 20,000 servers facing such a botnet? Client puzzles effectively become a mechanism for enforcing distributed rate limiting, and could be used to dramatically raise the cost of mounting such an attack.

  I have to think a lot more about the IoT/resource-constrained client problem, but I still don't think the existence of clients that would be  by this scheme



  TLS mailing list