Re: [TLS] TLS client puzzles

Kyle Rose <krose@krose.org> Wed, 29 June 2016 21:08 UTC

Return-Path: <krose@krose.org>
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 7797212D7F9 for <tls@ietfa.amsl.com>; Wed, 29 Jun 2016 14:08:27 -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, HTML_MESSAGE=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 (1024-bit key) header.d=krose.org
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 HIu8aFErcgOi for <tls@ietfa.amsl.com>; Wed, 29 Jun 2016 14:08:24 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 8E0CB12D7E7 for <tls@ietf.org>; Wed, 29 Jun 2016 14:08:23 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id w59so32470031qtd.3 for <tls@ietf.org>; Wed, 29 Jun 2016 14:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EAEQHoI2aKIUiEEClF0gDJkrpt7Nhv4l3szJnMzXg08=; b=UUiALkVTnAfuwihpbtMGSPrZCV/XFIwHbKTxnOMgC5t/iXUETO06loKUUPLCr5wncZ N39WHbjCW5S4g3HOdtrTZO1vzVufXHRxVljLXttFlN8fKVidjSZTzvKfqNkSmFy2d628 QSs4lrG5d3QPrhUiyTFCTvqsBrw+ZlvpS9pbE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EAEQHoI2aKIUiEEClF0gDJkrpt7Nhv4l3szJnMzXg08=; b=hLUeWnk1L2WnevP/5+MCsoe8UzaZl1ea5kVX/paNqTpttPeHkhvJNsEbHe1Nm2h8MT iYv5yXqjGhQCYuZ9LEl6BUtb1fmSwDW0oH9m7g69wK7j/vrSsDkZsB2TAuiPfjsnu1LW Kvo5awC5cuYkLLJaQjtc+YkN/7ipvsvYZN2iq1mhvvecJtShKGzGX5pjFp/EQaSPtRlZ 969drqNq7WyEdqVnrZ7uZgojdrom9592du/sppvOJsbDSFRzIpVc4U12wps5Un/F4RiB XwcS3iNw2wc8lR0naJV7A7RLcbB1cLpZbgNxnz4R0LocOlvFTBNlRCwFlTwYHzNNQGt/ d1yg==
X-Gm-Message-State: ALyK8tJOYr3DyXkweoQPIAqHlGj5pl4TMAI/gyNA85qmX3CeacBL9KywHVeUJXGrMktg7HOsn0dm9NqUufZ85g==
X-Received: by 10.200.41.163 with SMTP id 32mr17501644qts.101.1467234502706; Wed, 29 Jun 2016 14:08:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.80.66 with HTTP; Wed, 29 Jun 2016 14:08:22 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <CAFewVt4uUA-3X3M-ZmREo81p+MZp+72g9CX1d1Z7bK8G8AL9Vg@mail.gmail.com>
References: <CALW8-7Kv01Dw3YBiW20SBEScWqkup53xpCjy8834PpLDkgb4cg@mail.gmail.com> <CAFewVt4uUA-3X3M-ZmREo81p+MZp+72g9CX1d1Z7bK8G8AL9Vg@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 29 Jun 2016 17:08:22 -0400
Message-ID: <CAJU8_nWoTXLspS2mhwZLZhXxEMOYsWatU4T+UH10B+d=TExFJg@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary="001a1135763856305d0536712721"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_Z8v1kgLHGOp7mIJw0sN3wdp2qQ>
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: Wed, 29 Jun 2016 21:08:27 -0000

On Wed, Jun 29, 2016 at 3: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.
>

I think the appropriateness of client puzzles depends on what sorts of
tradeoffs we're willing to accept. Let's say we have a DoS attacker profile
that is not distinguishable from legitimate traffic, since that's the hard
case. Do we want to be able to serve *some* traffic during a DoS attack? If
we can't distinguish between legitimate users and attack traffic, we have
to assume everyone's a potential attacker. It seems what we're left with is
either rationing client requests or raising the cost of requests.

Rationing can be sliced up in any number of ways, but effectively amounts
to randomly denying some percentage of legitimate requests because we're
assuming attack traffic and legitimate traffic have the same profile. (In
reality, outside of NAT scenarios, we may be able to give immediate service
to existing clients and ration new clients; but we're assuming the horse is
a sphere for the sake of argument.)

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 problem you pointed out is that of clients that aren't capable of
absorbing the increased cost, such as low-power or memory-constrained
embedded devices. This is a legitimate concern, but I don't think it
universally disqualifies client puzzles. Maybe memory-hard puzzles aren't
appropriate for services that talk to IoT devices, but that doesn't mean
they aren't appropriate for websites that serve primarily to browsers. To
benefit from client puzzles on their websites, providers running IoT REST
services on the same server running their website may want to reconsider
that arrangement. Any client puzzle proposal must of course allow the
server to choose whether and when to issue a client puzzle, which in the
absence of authenticated client identity information should probably be
based on the expected client profile.

Tl;dr: memory-hard client puzzles are not universally appropriate as a DoS
defense, but I don't think that means they are never appropriate.

Kyle