Re: [TLS] Another IRINA bug in TLS

Hubert Kario <hkario@redhat.com> Mon, 25 May 2015 11:19 UTC

Return-Path: <hkario@redhat.com>
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 CE89A1B2BE4 for <tls@ietfa.amsl.com>; Mon, 25 May 2015 04:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 tGDJwyZgJYj8 for <tls@ietfa.amsl.com>; Mon, 25 May 2015 04:19:26 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1CC1B2BE5 for <tls@ietf.org>; Mon, 25 May 2015 04:19:26 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4PBJOuJ020341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 May 2015 07:19:24 -0400
Received: from pintsize.usersys.redhat.com (dhcp-0-197.brq.redhat.com [10.34.0.197]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4PBJMT7015037 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 May 2015 07:19:24 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 25 May 2015 13:19:16 +0200
Message-ID: <1741939.XqFprS2C0B@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.7 (Linux/3.19.7-200.fc21.x86_64; KDE/4.14.7; x86_64; ; )
In-Reply-To: <CAHOTMVJxjRgL7UqTWsLe+H57Atb_r0FGR6tbH+AS9GFSr+woCg@mail.gmail.com>
References: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com> <B515FE85-F5C2-4609-A673-936354CEB066@gmail.com> <CAHOTMVJxjRgL7UqTWsLe+H57Atb_r0FGR6tbH+AS9GFSr+woCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1758984.OKhEygvoUU"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/e0xabaVQy6dVAqApyU9vag4P-uY>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Subject: Re: [TLS] Another IRINA 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: Mon, 25 May 2015 11:19:31 -0000

On Friday 22 May 2015 14:12:51 Tony Arcieri wrote:
> On Fri, May 22, 2015 at 1:36 PM, Karthikeyan Bhargavan <
> 
> karthik.bhargavan@gmail.com> wrote:
> > 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.
> 
> +1 on this. The CFRG has already specified Curve25519 and Ed448-Goldilocks
> for use in this case:
> 
> https://tools.ietf.org/html/draft-irtf-cfrg-curves-02
> 
> Finite field D-H is slower and more problematic. I know people want it as a
> fallback in the event there's some sort of terrible breakage in ECC, but if
> that does happen, why not temporarily abandon forward secrecy until the
> problem can be addressed instead of switching to finite field D-H?

There is a second side to this coin.

Implementing ECDH (just like most ECC), is much harder that DH or RSA.
As such, for old software that receives just minimal maintenance it is easier 
to add support for advertising support for (big) FF-DHE than to add ECDHE.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic