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

Dave Garrett <> Wed, 03 June 2015 20:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AEF561ACE7F for <>; Wed, 3 Jun 2015 13:13:17 -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 yylymRUvhNfU for <>; Wed, 3 Jun 2015 13:13:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12ABE1ACD58 for <>; Wed, 3 Jun 2015 13:13:16 -0700 (PDT)
Received: by qkhq76 with SMTP id q76so12443913qkh.2 for <>; Wed, 03 Jun 2015 13:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=BalzGi3XsP1zT4Xmi3BIdWKuE0sCTRjeUQpOc5TBOSQ=; b=dtKT+10hlwR8FQGwzJhpIvGVdx62bjljthz9BBdLkTZpbBvAmtQ1D8IHov3yWy6ws+ mQ/m9LEL90HCfs4D6V1foI18ijxwggvmmWMbgN1uAdwePn2t0GLUrG6EpJerGKqUKrSI 93uuVgHdFjo9wcsrLH8eazoFyIhqZ185tLTImZ+8F2dXeUNXAdpGX4KzGEyDWqrpCYZF Wrqcwkf5sV9SBH2Z5loPkwZomN4rBDUaRA2h6r8hSrsfA3bUZMeeAfAuy60w/iIHNVAB cfCXerxfL7jt9IQhWljT1aGyPZK39TP9aWnDwNwd9y0d6J7ruanoFyQJQkYGZS/GTJ2U dwew==
X-Received: by with SMTP id b75mr63448790qkb.7.1433362395294; Wed, 03 Jun 2015 13:13:15 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id f192sm1011315qhc.37.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 13:13:14 -0700 (PDT)
From: Dave Garrett <>
To: Daniel Kahn Gillmor <>, Tony Arcieri <>
Date: Wed, 3 Jun 2015 16:13:13 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
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 20:13:17 -0000

On Wednesday, June 03, 2015 01:48:39 pm Daniel Kahn Gillmor wrote:
> On Wed 2015-06-03 13:23:36 -0400, Dave Garrett wrote:
> > 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.
> 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).

Yes, exactly.

> 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.

The topic brought up by Tony Arcieri was the apparent plague of old Java clients using TLS currently. A replacement set of cipher suites would transparently fix this in a simpler way. It adds more suites, yes, but it would ensure that this is only ever even _attempted_ to be negotiated between clients and servers that both support them properly.

A replacement set of FFDHE cipher suites would also be useful to more clearly segregate the clients and servers that support strong FFDHE from those that support weak parameters. A server supported suites scan would very clearly show the capabilities without having to check the extension for more detail. Even if this could all be technically implemented without new suite names/codepoints, doing so could be safer to manage and a bit more mistake-resistant.