Re: [TLS] Another INRIA bug in TLS

Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Sat, 23 May 2015 06:22 UTC

Return-Path: <karthikeyan.bhargavan@inria.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A911B1A90EE for <tls@ietfa.amsl.com>; Fri, 22 May 2015 23:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf9Dy0hWkhHr for <tls@ietfa.amsl.com>; Fri, 22 May 2015 23:22:00 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29621A90EA for <tls@ietf.org>; 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 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr 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 <karthikeyan.bhargavan@inria.fr>
In-Reply-To: <CABkgnnXUfmuhfudKT9K+TpPOzq0Bg1aoGDDAbLW+erktWzRUEA@mail.gmail.com>
Date: Sat, 23 May 2015 08:21:56 +0200
Message-Id: <578DE2AF-A139-4CDC-B71C-C67C28267FCB@inria.fr>
References: <9A043F3CF02CD34C8E74AC1594475C73AB029727@uxcn10-tdc05.UoA.auckland.ac.nz> <1432317148442.5357@microsoft.com> <87pp5snxha.fsf@alice.fifthhorseman.net> <BLUPR03MB13963BE37177243E5B89262B8CC00@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnXUfmuhfudKT9K+TpPOzq0Bg1aoGDDAbLW+erktWzRUEA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/o6XSCqTTJLdfbjUzqQ3U2lG11bk>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Another INRIA bug in TLS
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 May 2015 06:22:04 -0000

> On 22 May 2015 at 14:09, Andrei Popov <Andrei.Popov@microsoft.com>; 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] http://www.ietf.org/mail-archive/web/tls/current/msg16496.html
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls