Re: [TLS] Call for consensus to remove anonymous DH

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 17 September 2015 00:42 UTC

Return-Path: <dkg@fifthhorseman.net>
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 5CB061A887A for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 17:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XN04-f4xIpT1 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 17:42:43 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 519751A6FFB for <tls@ietf.org>; Wed, 16 Sep 2015 17:42:43 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A7972F984; Wed, 16 Sep 2015 20:42:32 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 9E0AF1FF67; Wed, 16 Sep 2015 20:42:04 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>, tls@ietf.org
In-Reply-To: <20150917002111.GD21942@mournblade.imrryr.org>
References: <CAOgPGoBT9C=pWebXShqxhbOsnqK+OZe=-n-SvZ_pH-dAtRaWXQ@mail.gmail.com> <CAFewVt7_23v18HpzzDy4ew1h66iNTBOSdP+CVBgc9T-4Z3isfA@mail.gmail.com> <20150916210113.GP13294@localhost> <CABcZeBPY6JRnLiqd=-aQQ+8kZGHa3TujSr9+hn1CSt1B_X-r=Q@mail.gmail.com> <CAFewVt64QphK5=WtAZhN8A7uhjmMZ1wc0nLOKvS8sgTRwY_vkg@mail.gmail.com> <CABcZeBM9-pa5Cn0JR0vJhiN7H=86GcmFPKgriebNi28r0zTBnQ@mail.gmail.com> <20150917002111.GD21942@mournblade.imrryr.org>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 16 Sep 2015 20:42:04 -0400
Message-ID: <87d1xh6fmr.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/EdwHQQjNjN-B952FAGXLC1P3Nf8>
Subject: Re: [TLS] Call for consensus to remove anonymous DH
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: Thu, 17 Sep 2015 00:42:44 -0000

On Wed 2015-09-16 20:21:11 -0400, Viktor Dukhovni wrote:
> The difference between raw public keys (RFC7250 RPK) and anon is:
>
>     - PRO: Dropping anon simplifies the implementation and reduces
>       cipher count.
>
>     - PRO: Raw keys may facilitate TOFU pinning.
>
>     - CON: Raw keys are not yet implemented in any toolkits I've seen
>       (a temporary setback perhaps).
>
>     - CON: Raw keys send more traffic (public key in certificate
>       message, plus signature of key agreement).  Byte counts can
>       matter in some environments.
>
>     - CON: Raw keys consume more CPU (signing the key agreement).
>
>     - CON: Servers lose a simple signal that the client is not
>       bothering with authentication.

and:

      - PRO: passive attackers on the network lose a simple signal tha
        tthe client is not bothering with authentication.

> The costs are likely noticeable for 4096-bit RSA keys.

A server concerned about CPU or bandwidth costs who would have preferred
anon_DH suites would be silly to select 4096-bit RSA, whether RPK or
cert.  They should choose some small ECC key.

A client concerned about CPU who would have been fine with anon_DH will
simply not verify the signature at all.

So that leaves clients concerned about bandwidth, who pretty much have
no choice but to eat the handshake message that the server sends them
anyway :/

   --dkg