Re: [TLS] TLS Client Puzzles

Tony Arcieri <bascule@gmail.com> Tue, 07 July 2015 01:51 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133C11A00DD for <tls@ietfa.amsl.com>; Mon, 6 Jul 2015 18:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 IMRrkc-w0VM7 for <tls@ietfa.amsl.com>; Mon, 6 Jul 2015 18:51:31 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 8B6A61A00CA for <tls@ietf.org>; Mon, 6 Jul 2015 18:51:31 -0700 (PDT)
Received: by oihr66 with SMTP id r66so75375256oih.2 for <tls@ietf.org>; Mon, 06 Jul 2015 18:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=EKg/Dh3jsNZF3CsTiEpX5rIPqP1QBnFGd0YOAZyYFWE=; b=usTbByDGeaMQD8Nf7IU6ykeHJCxm3KKmawaJ6SUcb/zhwEhj+awMR0YLQhmIg0LZXj fHf/RbMT9sQh8mfO7GGkZUTB2gaukh7Md3CQy0kcK18aajZwZ31g0QebH7L1XMMTnAUH SoYSOv+ZfmLAYXVgMWfXpCbRb9MjqhMpBQ2J8VvspgGRJIf3nIuzJ2yqoBRCZm8KRGuR rI+wIvJf9EugN6CXcQmg3Tfsh88ck4rJGwsfgxSGp4ir4lhOITJji9vwgW7f5cTqdmWK +p2ZBXU+wJpIVERLmbf4v6Xr1ZZs/EyDOhbATAHYx+AjQpNN7GFOpjryLZ1oSt625LbS VDMA==
X-Received: by 10.182.186.2 with SMTP id fg2mr1610690obc.35.1436233890973; Mon, 06 Jul 2015 18:51:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.113.142 with HTTP; Mon, 6 Jul 2015 18:51:11 -0700 (PDT)
In-Reply-To: <CAKC-DJjfq_Lw6ovX=sVFt3=4q_4CYo_N79PZFx+LrGj7DbLK+w@mail.gmail.com>
References: <CAKC-DJjfq_Lw6ovX=sVFt3=4q_4CYo_N79PZFx+LrGj7DbLK+w@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Mon, 06 Jul 2015 18:51:11 -0700
Message-ID: <CAHOTMVKYS75xqeVsHmmuxRFMRqgAVJ_U-1c825LMn8+h+QmOdA@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Content-Type: multipart/alternative; boundary="089e0141a71ae2cd37051a3f4205"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BNq_1hvRvIyrIPmd4-wLXBA6zbE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Client Puzzles
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 07 Jul 2015 01:51:33 -0000

On Thu, Jul 2, 2015 at 2:40 PM, Erik Nygren <erik+ietf@nygren.org> wrote:

> Following a discussion last year in Denver, I've written up a proposal
> for a TLS Client Puzzles extension.
>

I'm sorry, but I think this is the wrong approach.

I assume you're trying to solve the asymmetrical computation requirements
of RSA, a.k.a. the "THC DoS attack"

If you're using RSA for key exchange, don't. It's very broken in more ways
than DoS.
If you're using RSA for signatures, it should be deprecated and phased out.

Trying to solve the latter problem by complecting TLS is likewise something
I oppose.

Moving to ECC-based signatures (ECDSA or EdDSA or
CFRG-yet-to-be-standardized-signatures) would obviate this problem without
complecting the TLS protocol. ECC punts the computational burden to the
client, elegantly solving this problem by using the algorithms we want to
move to anyway.

Complexity is the enemy of security.

I prefer simplicity. To solve this same problem, I would prefer RSA
diediedie. I know that's a stretch, but I would prefer TLS gravitate
towards simple solutions than adding complex band-aids.

-- 
Tony Arcieri