Re: [TLS] TLS client puzzles

Yoav Nir <ynir.ietf@gmail.com> Thu, 30 June 2016 08:23 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1A12D624 for <tls@ietfa.amsl.com>; Thu, 30 Jun 2016 01:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZZHaWoyRr5Ed for <tls@ietfa.amsl.com>; Thu, 30 Jun 2016 01:23:53 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 29C7012D536 for <tls@ietf.org>; Thu, 30 Jun 2016 01:23:53 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id r201so106902434wme.1 for <tls@ietf.org>; Thu, 30 Jun 2016 01:23:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r/MVjKbI6J68SlZbyZlxT2uZ3BVk4mfZYDMOZa/+bOs=; b=vHixMdK+jbljLDhtNJr24lgZj0XQ+tD5UvxTPa4TXAVtgdK4vxOFWDlZr+Ot23rFwd AkOJ7oJoefRQLtOLXTREGNMfUk5VqDQpNO+sOX/WH1ODLFImmsmn5j8O1OmLpnHKYtdZ S0k/x48rWPSBLeDdEmAOZ+bueSeY2HXAgzVWIcCxNno+/BWAmgatqiNNpzc/As5O4xDW wjG1wM0F6L08W4lrT4uu3hBnbucgdLSIC7usf3cvIA5qGFRZo7tdU/wt3eeAM8W/vh2a q6lw0xolyPPDe8cMwpI4L2xA843GQLzgap+ZXn0vnG6RyHhiRnBlrcIDtRv3xMg3cPUA oBSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r/MVjKbI6J68SlZbyZlxT2uZ3BVk4mfZYDMOZa/+bOs=; b=Tq48JDU6csnvIUF0TWt58g2DFMml5Nffk+Pq4p2nr0SN2invw+sxLJIY9IhpqXKHOC EYfHGRloqaRzlBdNp+4KKY5uhRCuU5E6Uj1q9IQ6XwErEumzFnfcu69f+h7IVgh343X3 H6pHjAxBZ9+GgWKn4ovF2/cUQoiTAwzIpyF8vou6EnckxELLo5eI5IlvlRqlsRrkoZg3 3yS+u+wv6W3143NIy9Y3X/r5o+Sp8zkeeCgUQhZCpPZoCYXd0qquHJxBHtiXPPSVfp2f OnXT5JGJDCvkd71SG87XwQ8W1OOjUCciqIZ6tFu18zwkx8/rlLDdBzeAHNrg8xM/fThw oZMw==
X-Gm-Message-State: ALyK8tKg8OvlV+4MZKDZWiDQ33oe1pcs/HQLtblnT1uVEq/OuXqW0+4UbzfZfDyS7XGXiQ==
X-Received: by 10.28.67.69 with SMTP id q66mr24800164wma.81.1467275031631; Thu, 30 Jun 2016 01:23:51 -0700 (PDT)
Received: from [172.24.251.18] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id u4sm2009750wjz.4.2016.06.30.01.23.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Jun 2016 01:23:50 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAFewVt4uUA-3X3M-ZmREo81p+MZp+72g9CX1d1Z7bK8G8AL9Vg@mail.gmail.com>
Date: Thu, 30 Jun 2016 11:23:47 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBD9F053-10DC-49AF-BD97-01182AFFBBB3@gmail.com>
References: <CALW8-7Kv01Dw3YBiW20SBEScWqkup53xpCjy8834PpLDkgb4cg@mail.gmail.com> <CAFewVt4uUA-3X3M-ZmREo81p+MZp+72g9CX1d1Z7bK8G8AL9Vg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ns6gFjg4DKVjiO5I0tO4zxX7b-A>
Cc: Dmitry Khovratovich <khovratovich@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS client puzzles
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 30 Jun 2016 08:23:55 -0000

> On 29 Jun 2016, at 10:25 PM, Brian Smith <brian@briansmith.org> wrote:
> 
> Dmitry Khovratovich <khovratovich@gmail.com> wrote:
>> It allows cheap and memoryless verification by the server even though the
>> puzzle solving guaranteely requires dozens of MB of RAM from a client
> 
> I feel like this is impractical simply because lots of people are
> building HTTPS clients that don't even have dozens of MB of RAM total.
> I think we should avoid doing anything that requires the client to
> have more than ~16KB of memory total to devote to TLS stuff.
> Otherwise, we force the internet to have an architecture where all
> small devices require a smart proxy to solve these puzzles for them
> and do other things.

Hi, Brian.

Having clients commit resources to solve puzzles is always a balancing act between the capabilities of legitimate clients and those of the attackers. With CPU-intensive puzzles the attackers tend to be fast desktops and servers, while the legitimate clients could be as weak as a smart-object or as powerful as a server. It’s hard to find good parameters that will allow the oldest phone in while slowing the attacker down significantly. The same, as you pointed out, is true for RAM-intensive puzzles.

For the web the legitimate clients fall into two categories: Desktops and laptops on the one hand, and mobile phones on the other. For CPU-intensive puzzles their capabilities are far apart, so you’d have to tune the puzzle to the capabilities of the weakest phone, or else accept that phones are cut off during a severe DDoS attack.  With RAM, however, the differences are less pronounced. Both kinds of legitimate clients can afford to devote dozens of MB of RAM. The same is not true for IoT, but I’m talking about the real web here, not data services over HTTPS.

I think for this particular case RAM-intensive puzzles make sense.

Yoav