Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt

Tony Arcieri <> Wed, 03 June 2015 08:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E433C1B366F for <>; Wed, 3 Jun 2015 01:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lDqNYFmQ_VvY for <>; Wed, 3 Jun 2015 01:49:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E3851B366E for <>; Wed, 3 Jun 2015 01:49:16 -0700 (PDT)
Received: by objn8 with SMTP id n8so2440041obj.3 for <>; Wed, 03 Jun 2015 01:49:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/GsP17QBnpODNli5KU9o/f4v2o7JNJjSs28ztdPkyN4=; b=ftLtAeZyq0YEOCXASAkohJwFpbNatk5IHIJLU324FrDFNsHcO2GvVG+lX7KtHrsNpN h9oIjCC7PxYegaN2Pxod/U0Zu+waClwK7lcZE/kSSGyWoQ/HePE9AbciGKbRHQbk2lyl gU/w7xYvIbjLy2pWL0ILAJswfx6geEzMuz/8Vx1w9vkZu2juULZEJdsWCx/33GgCdbz5 e+zOgTIdgeY5sQvXOac/2jTjqGmRe5xsV8v1EyA/P2Xio7JALpQGknZwxM7b+0VXWBEz RitqgYinqxUceZcN/pdvGL1CFxLm1pAroC8l5ND/Jxi98AqBvXCJrz/bGRkUeRuic6M4 Ysiw==
X-Received: by with SMTP id x64mr24877828oie.50.1433321356550; Wed, 03 Jun 2015 01:49:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 3 Jun 2015 01:48:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <m2lhg1b8us.fsf@localhost.localdomain> <> <BLU177-W17E87DB68F54CE64BDC44C3B40@phx.gbl> <> <BLU177-W1EA1B34A70F648FD8C139C3B40@phx.gbl> <> <> <> <>
From: Tony Arcieri <>
Date: Wed, 3 Jun 2015 01:48:56 -0700
Message-ID: <>
To: Peter Gutmann <>
Content-Type: multipart/alternative; boundary=001a113cefa44e695f05179922c9
Archived-At: <>
Cc: Geoffrey Keating <>, TLS WG <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Jun 2015 08:49:19 -0000

On Wed, Jun 3, 2015 at 1:43 AM, Peter Gutmann <>

>  You seem to want everyone to change their behaviour in order to
> accommodate
> the fact that you've chosen to use a broken, buggy implementation

These aren't clients under my control. I am talking about an entire
language ecosystem here, not just my little corner of the world. But even
if they were my clients, they wouldn't negotiate DHE anyway, because most
configurations would prefer ECDHE.

The "accommodation" you're defending is using finite-field Diffie-Hellman.
Most clients support ECDH(E) and don't need to support finite-field

Finite field Diffie-Hellman is a slow, outmoded legacy key exchange
algorithm that in my opinion should completely be abandoned.

I didn't even bring up Java, but it was cited as a reason for FFDHE to
exist. However Java 7 and 8 clients would prefer ECDHE anyway. As they
should, it's faster and uses smaller keys.

This is a case of some legacy gunk left over from the early days of TLS
breaking key exchange for clients that support better algorithms.

We can either double down on the gunk, or shut it off.

*In practice* I have been telling people to shut it off and so far it's
been a successful solution to the problem.

Why should we keep this legacy gunk around? Who is it helping?

Tony Arcieri