Re: [TLS] Another INRIA bug in TLS

Karthikeyan Bhargavan <> Sat, 23 May 2015 06:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A911B1A90EE for <>; Fri, 22 May 2015 23:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nf9Dy0hWkhHr for <>; Fri, 22 May 2015 23:22:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E29621A90EA for <>; Fri, 22 May 2015 23:21:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,480,1427752800"; d="asc'?scan'208";a="126054587"
Received: from (HELO []) ([]) by with ESMTP/TLS/AES128-SHA; 23 May 2015 08:21:57 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_B3873D66-92A7-42DC-A9E1-A238439E6D50"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Karthikeyan Bhargavan <>
In-Reply-To: <>
Date: Sat, 23 May 2015 08:21:56 +0200
Message-Id: <>
References: <> <> <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Another INRIA bug in TLS
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: Sat, 23 May 2015 06:22:04 -0000

> On 22 May 2015 at 14:09, Andrei Popov <> wrote:
>> In the long term, it may become possible to only allow DHE cipher suites when a known group has been negotiated using draft-ietf-tls-negotiated-ff-dhe.
> That time might have come sooner, if it weren't for the
> misapprehension people have been given regarding custom groups off the
> logjam mitigation advice.  I think that Karthik's clarification [1] is
> much clearer than the message that has been propagated.

Apologies if the paper led to any confusion on this, we were summarising lessons for
all DH-based protocols, not just TLS.

Yes, we *DO* support wide deployment of the FF-DHE draft, because
(a) 2048-bit groups are believed to be currently out of reach of the NFS-based technique considered in our paper,
(b) generating safe primes based on a public value like “e” is believed to avoid trapdoors (with high probability).

The “avoid fixed groups” recommendation applies to 1024 bits (and any other group-size for which
precomputation becomes feasible.)

Having said that, it would be good to set up a rigorous mechanism for “retiring” DH groups and EC curves
as their expiry date gets closer. DHE_EXPORT has survived 15 years after deprecation. Cryptographers
have recommended against using 1024-bit DH groups for a few years now. We’re going to hit the same
problem with curves at some point.

One option is to periodically obsolete drafts like FF-DHE, but would that just make a mess for implementations?

> [1]
> _______________________________________________
> TLS mailing list