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

Peter Bowen <> Wed, 03 June 2015 16:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE3861ACE9C for <>; Wed, 3 Jun 2015 09:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 72Q8heKq7lyf for <>; Wed, 3 Jun 2015 09:44:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 795771ACF57 for <>; Wed, 3 Jun 2015 09:44:08 -0700 (PDT)
Received: by pdbki1 with SMTP id ki1so11243539pdb.1 for <>; Wed, 03 Jun 2015 09:44:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AwIRa24u/LMBtOYz6hu7Hvg1h9mBtNlONfE03nClxLk=; b=TxSA0iQJsi1JcCCL4sojCm0/dJE6vG3/FqP2acG+cSePShJf0lzIlf9QQC47gZKMTm NRURfBdGED0ex4zDmZuvcyXdfhQmfnxKRe+hB/KOXA32pf1K/v0h43ZB+/X3/srBep3n vvwHURlrPdTAZ959dM8RFZXUHtWDXZMhOoT0ncMfwHlkhudm7BJFFlBrBQMkpkzW2ugP pl4En2Tkhw608LugEWN0qJ6QZXwWVjUTboAxvm6aFoC/dhYzs107l9lovduvxtsDQ3pS F5hhMDHeFDzwry7Bu04U7PVUFEArqq/Yx/VA+1Kp6ML272j8pSC+t/ZPxWo55qM5vKKb D6lA==
MIME-Version: 1.0
X-Received: by with SMTP id i8mr23857956pbq.74.1433349848191; Wed, 03 Jun 2015 09:44:08 -0700 (PDT)
Received: by with HTTP; Wed, 3 Jun 2015 09:44:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <m2lhg1b8us.fsf@localhost.localdomain> <> <BLU177-W17E87DB68F54CE64BDC44C3B40@phx.gbl> <> <BLU177-W1EA1B34A70F648FD8C139C3B40@phx.gbl> <> <> <> <> <>
Date: Wed, 3 Jun 2015 09:44:08 -0700
Message-ID: <>
From: Peter Bowen <>
To: Tony Arcieri <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: TLS WG <>, Geoffrey Keating <>
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 16:44:10 -0000

On Wed, Jun 3, 2015 at 1:48 AM, Tony Arcieri <> wrote:
> On Wed, Jun 3, 2015 at 1:43 AM, Peter Gutmann <>
> wrote:
>> 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
> Diffie-Hellman.
> 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.

There are three classes of clients today:
1) Clients that support ECDH key exchange (with at least the NIST
P-256 and NIST P-384 curves)
2) Clients that do not support ECDH but support FFDH with larger modp sizes
3) Clients that do not support ECDH but support FFDH only with smaller
modp sizes (e.g. max size is only 1024 bits or 2048 bits)

This draft supposes that there will continue to be clients that fall
into the second class for the foreseeable future and given them a way
to declare that they are not in the third class.  While we would all
like to see every client in the first class, I don't think that is a
real option for a few more years.  Until then, we should allow clients
to indicate that they will accept reasonable modp sizes.  That was a
server can choose to allow them to use FFDH for key exchange but not
offer FFDH for other clients.