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

Daniel Kahn Gillmor <> Wed, 03 June 2015 17:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B3AC81ACCFB for <>; Wed, 3 Jun 2015 10:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wbh4YgNvEV1K for <>; Wed, 3 Jun 2015 10:49:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E18D01A9236 for <>; Wed, 3 Jun 2015 10:49:03 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 7D90BF984; Wed, 3 Jun 2015 13:49:01 -0400 (EDT)
Received: by (Postfix, from userid 1000) id 51C2D1FF76; Wed, 3 Jun 2015 13:48:39 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Dave Garrett <>, Tony Arcieri <>
In-Reply-To: <>
References: <> <> <> <>
User-Agent: Notmuch/0.20 ( Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Wed, 03 Jun 2015 13:48:39 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: "<>" <>, 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 17:49:05 -0000

On Wed 2015-06-03 13:23:36 -0400, Dave Garrett wrote:
> On Wednesday, June 03, 2015 04:20:15 am Tony Arcieri wrote:
>> On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett <> wrote:
>> > Well... here's a way it could:
>> > 1) Deprecate/prohibit all "DH(E)_*" cipher suites
>> I'm a bit unclear on this, but I think that's actually happening as part of TLS 1.3?
> No, that's what you're proposing with a diediedie. (seems to have been a miscommunication here)
> DH_* (non-ephemeral) are being deprecated in TLS 1.3. DHE_* are still
> in TLS 1.3. You're argument is that non-ECC DH(E) is harmful because
> Java is crap and chokes on it. (yeah, Java should be fixed, but it is
> crap and out there and breaking, and getting rid of DH(E) would fix
> that)
> What I said was:
>> 1) Deprecate/prohibit all "DH(E)_*" cipher suites
>> 2) Create a new set of "FFDHE_*" cipher suites to replace them that only allow strong groups (3072+)
> My suggestion is to do exactly what you propose, publish a DH(E)
> diediedie, but in the same RFC standardize a new set of DHE cipher
> suites with strong requirements using a new prefix (e.g. FFDHE) and
> new codepoint assignments. Servers supporting these new suites will
> never negotiate them with old clients that don't support them, but
> newer clients that add support will be able to negotiate DHE using the
> new cipher suites.
> It's a cake-and-eat-it-too suggestion. Kill old DH(E) and replace it
> with a limited set of new suites that are only usable with strong
> groups and only supported by new clients.

Alternately, we can get the same functionality with the
negotiated-ff-dhe draft:

 * servers compatible with the draft can choose to never negotiate ffdhe
   with clients that don't advertise support.

 * newer client will be able to negotiate ffdhe with these servers by
   advertising support.

The main difference depends on what newer clients want old servers to do:

   If clients are willing for old servers to go ahead and negotiate
   FFDHE ciphersuites even if their parameters might be dubious, then in
   your proposal they need to offer both sets of ciphersuites (possibly
   increasing the list of ciphersuites beyond 64, which may tickle other
   bugs [0])   

   If clients want old servers to never negotiate an FFDHE ciphersuite
   unless they're offering good parameters, then under your proposal
   they simply offer the new ciphersuites.  Under the current
   negotiated-ff-dhe draft, a client receiving bad parameters from the
   server has to abort a connection (and can subsequently re-try without
   listing any FFDHE ciphersuites if it wants).

For TLS 1.3, i'm expecting that any FFDHE ciphersuites will have a
radically different handshake, so very little of this is relevant (plus,
it will be TLS 1.3, so we can treat the existing ciphersuites
differently based on the version of the protocol in use).  So the
negotiated-ff-dhe draft aimed for the simplest, most minimal change for
1.2 and earlier.



[0] e.g. see Message-ID: 20131107213744.GQ18713@localhost on this
    mailing list, "Windows 2003 TLS 64 ciphersuite limit" from Nico
    Williams, 2013-11-07