Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

Geoffrey Keating <> Fri, 19 August 2016 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 213B012DA2A for <>; Fri, 19 Aug 2016 11:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OOq9XO9j2-ru for <>; Fri, 19 Aug 2016 11:35:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1E0312DA29 for <>; Fri, 19 Aug 2016 11:35:45 -0700 (PDT)
Received: by (Postfix, from userid 501) id 5906133D20D; Fri, 19 Aug 2016 18:35:45 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Peter Gutmann <>
References: <> <> <> <> <>
From: Geoffrey Keating <>
Date: 19 Aug 2016 11:35:45 -0700
In-Reply-To: <>
Message-ID: <m260qwppxa.fsf@localhost.localdomain>
Lines: 22
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
X-Mailman-Version: 2.1.17
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: Fri, 19 Aug 2016 18:35:49 -0000

Peter Gutmann <> writes:

> The problem is that 7919 doesn't say "I want to do DHE, if possible
> with these parameters", it says "I will only accept DHE if you use
> these parameters, otherwise you cannot use DHE but must drop back to
> RSA".  Talk about cutting off your nose to spite your face, you'd
> have to have rocks in your head to want to break your implementation
> like that.

Actually, my problem with the RFC is the reverse.  If you have an
implementation which won't accept certain DH groups, and those are
extremely common in legacy software (1024-bit, for example), there's
no way to stop those legacy implementations ignoring the extension and
choosing DH, which you will then have to reject, doubling connection
establishment time.

So Apple's client still has DH off.

However I don't see a helpful solution to this; the obvious thing is
to have a new ciphersuite, but it's hard to see how that would be
worth the effort if it requires new implementations and ECDHE is
already standardised and already implemented in many places.