Re: [TLS] Another IRINA bug in TLS

Kurt Roeckx <> Sat, 23 May 2015 12:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8D4251A1A4E for <>; Sat, 23 May 2015 05:11:58 -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_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GndVn_8OPDTU for <>; Sat, 23 May 2015 05:11:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 203961A1A42 for <>; Sat, 23 May 2015 05:11:54 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 467AC1C21B7; Sat, 23 May 2015 14:11:52 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 152E61FE014F; Sat, 23 May 2015 14:11:52 +0200 (CEST)
Date: Sat, 23 May 2015 14:11:52 +0200
From: Kurt Roeckx <>
To: Karthikeyan Bhargavan <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Another IRINA 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 12:11:58 -0000

On Fri, May 22, 2015 at 10:36:57PM +0200, Karthikeyan Bhargavan wrote:
> > I think the authors felt the same. But in Section 4 of the paper, they said:
> As one of the authors of the paper, let me try to clarify our recommendations a little bit.
> First, we only know what is broken, and can only make precise recommendations for avoiding the attacks in the paper.
> Figuring out what's a good long-term alternative is for a community forum like this to decide. 
> If we were to make a recommendation for TLS, at least as it is used on the web, it would be as follows, 
> in decreasing order of preference:
> 1) Switch to ECDHE. 
>     It is faster, and the kinds of attacks discussed in our paper have not (yet) been shown to be effective for the common curves.
>     As usual, we need to be wary of weak curves (160-bit) or curves that may have been generated maliciously.
>     We leave it to the EC folks to tell us what are good curves to use.
> 2) Switch to stronger (>=2048-bit) DHE groups.
>     If ECDHE is unavailable, we are happy (today) with >= 2048 groups as suggested in the FF-DHE draft.
>     As usual, we have to be wary of how these groups are generated, since there is the possibility of trapdoors being built in.
>     Using well known constants such as pi or e as the basis for prime generation (e is used in FF-DHE) is, as far as we know, 
>     a safe technique for generating a group with a low probability of a trapdoor.

The site currently says:
| If you run a server...
| If you have a web or mail server, you should disable support for
| export cipher suites and generate a unique 2048-bit Diffie-Hellman
| group.

Should that be changed to "and use a 2048-bit Diffie-Hellman