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

Dave Garrett <> Wed, 03 June 2015 21:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7A7371B2A70 for <>; Wed, 3 Jun 2015 14:36:35 -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 AikpOmk7GF0U for <>; Wed, 3 Jun 2015 14:36:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC1561AD0D2 for <>; Wed, 3 Jun 2015 14:36:33 -0700 (PDT)
Received: by qkx62 with SMTP id 62so13762912qkx.3 for <>; Wed, 03 Jun 2015 14:36:33 -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=aE2LFyjIYzlfYqFRxKMNont5S8wIk4Z7NKAmFO6cQ5Y=; b=zYK3O7gFCGutTaSuiMyJc4o10R2NRW9SB312Puf9IN+GBxSk9TeL9P8HodDXcV5Wqq GPamnAG/cB1EsznepXjcYwf9PZY4nq7W+UGGO/qpDlpDLE+1n9HTHXq8CrsSyHDtsKln VTPQTOs6XtIjsRlw0V9domiVfzSh+YxVyJAqkGpAhv5chZT3a9ALUN4zAT3biRkikGoQ 2aGe8sx46UWc1AS2Q+8qwOsjmhmPbH6WDeouqp0H6w+HTypeslOH5bwfZgXip3eSJu5h ELRfH8KCtEy5uVYD74l6NK+XijrMOsv3N05tj+weln1W53wutyS6eejG0a6deI/Gq5ZX pqDw==
X-Received: by with SMTP id 6mr63881282qkz.13.1433367393044; Wed, 03 Jun 2015 14:36:33 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 9sm1148426qhy.1.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Jun 2015 14:36:32 -0700 (PDT)
From: Dave Garrett <>
To: Tony Arcieri <>, Daniel Kahn Gillmor <>
Date: Wed, 3 Jun 2015 17:36:30 -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: quoted-printable
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 21:36:35 -0000

On Wednesday, June 03, 2015 04:50:59 pm Tony Arcieri wrote:
> That said, I think everyone is convincing me FFDHE *might* be a good idea.
> Particularly persuasive is Ilari's argument that with some tiny changes,
> ECDHE and FFDHE can be unified.

Actually, doing that completely is probably better than adding new suites. Just do "DH(E)_*" diediedie and allow new implementations that negotiate "ECDHE_*" to pick either a strong curve to do ECDHE or a strong group to do FFDHE, without needing to specify it in the suite.

Back in the discussion about ways to improve negotiation of capabilities to deal with the suite combinatorial explosion, the general consensus was that the simplest a la cart route would be to only negotiate symmetric ciphers via the suites and pick the rest via extensions, ignoring the parts in the suite. The usage of FFDHE or ECDHE would be based on what gets negotiated via the “supported_groups” extension. This could be the general way forward for TLS 1.3+ and for older TLS clients that want to deprecate "DH(E)_*" suites as well.

With this route, all endpoints that negotiate the use of the “supported_groups” extension would:
1) Consider all "(EC)DHE_*" suites to be equivalent; any *DHE* suite would use the same negotiation algorithm. (ephemeral only might be simplest; just ditch non-FS)
2) Usage of FFDHE or ECDHE would be chosen based on the negotiated named group/curve based on client priority.
3) Endpoints that no longer wish to ever negotiate any weak DHE would stop offering all "DHE_*" suites, which would now be considered deprecated.
4) The "ECDHE" prefix on suites would now essentially mean "ECC capable", rather than "only ECC".