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

Peter Gutmann <> Wed, 17 August 2016 11:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F27F12D91B for <>; Wed, 17 Aug 2016 04:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mtek8kDsTXjU for <>; Wed, 17 Aug 2016 04:43:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C53BD12D9B3 for <>; Wed, 17 Aug 2016 04:34:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1471433653; x=1502969653; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cma6hEzCCAUJTgF6cNpksUa/aTjWZUkrhashFFia7uc=; b=04lNdKJqre47dR8DEYtosdeL6hBjUhcrjSswOt7zAQDl/3MJJMIgG6Xd 9IopJpWVz6J7yNJExopaajV3MIY/3KXmQRTjYd2RODzuM/ClR8k8xvb9x lfF++RJne2UR2EktV2JhCGb8JXKltU2lpvDJS/mn3ASNrGPgQ3OD32Vo4 3qAly8e0L2q5TjtN9Hbhyxo048v2mVUhFxzcVHKb/fyW3GB7jefNvIIlx JU3J8xGzRJXjbHNOTYQk03RcDghSgDX2o0VNWPAmvllhorpK3s+25qs3h FmgkXTU2mmpNnlXS+/ZIaRhizutsKI6jEPVeoIScytm3gTvgffS+EGmXS A==;
X-IronPort-AV: E=Sophos;i="5.28,529,1464609600"; d="scan'208";a="102530104"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 17 Aug 2016 23:34:11 +1200
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Wed, 17 Aug 2016 23:34:10 +1200
From: Peter Gutmann <>
To: "" <>
Thread-Topic: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
Thread-Index: AdH3qzVttHomztzDTIKlIRH23NqfIv//fPYAgAIjA00=
Date: Wed, 17 Aug 2016 11:34:10 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
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: Wed, 17 Aug 2016 11:43:15 -0000

Viktor Dukhovni <> writes:

>The client is expected to send a complete list of *all* the groups it
>supports if it supports (any of) the new designated groups. Which means that
>clients that support these groups will use only these groups with servers
>that likewise suppose these groups, and will not use FFDHE when the client
>group list and the server group list don't overlap (which is seems unlikely).

But the text above says that if the server doesn't support what the client
asks for, you can't use PFS/DH/FFDHE/whatever you want to call it at all.  I
don't care whether the server does exactly ffdhe2048 or not, I'll take
ffdhe2048 if available, otherwise anything DHE as long as it's over about 1536
bits, and for a lot of clients my code is used in, under about 3K bits because
they don't have the CPU for more than that, and in addition don't need that
level of security.  However, what the above text says is that if the server
can't do exactly ffdhe2048 then it's not allowed to do any DHE at all and has
to use RSA.

>There's no guess, the client sends its full list of supported groups, and the
>server picks the one it likes.

... and if the client doesn't get it exactly right, the server has to fall
back to RSA rather than use another DHE suite of its choosing.