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

Peter Gutmann <> Tue, 16 August 2016 10:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DA3312D727 for <>; Tue, 16 Aug 2016 03:44:56 -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 5nLxiBpJQ4oE for <>; Tue, 16 Aug 2016 03:44:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25D1412D672 for <>; Tue, 16 Aug 2016 03:44:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1471344291; x=1502880291; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Iog6VSTCO5tvBJ3tzePrsgo8/m+K8nX4dsIog08nBJs=; b=NFpy0Q7of5PCCidnbfDucXIWuMqdnsFAynL2BoBa8b8i8PfQBfC+vcnT IZA1rXoyOWFeaVuQr5A353qC0vIWFm5RidRTVoa2ATUNPs3BxX8WKIrNr 5w9FLDAjOMmK8mQIwJVS/gfYnk2d6z3ms4+wG3HBMYPcJbzjHygflxikH OpM7ejDBH4m6dm9/6tC8WQ1rx6pYFe3BefbKTPNPgvaaWkCikxQCORzod jP5dqskeUnHL8Kk3UUt1QShbnnPwD9UrwSC9TtAr3ERpos2xpc22RabhJ R2S8YybKu9obQydDS1ugOVfEz7xCgT5t0BdbPJjVV63AjelcAz0/UpzqY w==;
X-IronPort-AV: E=Sophos;i="5.28,529,1464609600"; d="scan'208";a="102383480"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 16 Aug 2016 22:44:49 +1200
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Tue, 16 Aug 2016 22:44:48 +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: AdH3qzVttHomztzDTIKlIRH23NqfIg==
Date: Tue, 16 Aug 2016 10:44:47 +0000
Message-ID: <>
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: Tue, 16 Aug 2016 10:44:56 -0000

I've been looking through this in a bit more detail and have found some pretty
problematic text in there...

   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.

As far as I can see what this text is saying is that if the client can't guess
in advance which PFS suite/group the server knows about, the server must
disable use of PFS.  In other words instead of saying "give me a PFS suite,
preferably with this group", it's saying "give me a PFS suite with exactly
this group and if you can't do that, don't do PFS".  This seems like a pretty
awful way to handle things.

This is reinforced by:

   A compatible TLS server that receives the Supported Groups extension
   with FFDHE codepoints in it and that selects an FFDHE cipher suite
   MUST select one of the client's offered groups.

In my mind this makes the FFDHE extension so toxic to use that I'd rather not
support it at all, because it disables PFS unless you're really lucky in
guessing what the server can do.  Either that or it'll be like certain parts
of TLS 1.2 where everyone knows that you need to ignore what the spec says in
order for things to work...