Re: [TLS] Another IRINA bug in TLS

Tony Arcieri <bascule@gmail.com> Fri, 22 May 2015 21:13 UTC

Return-Path: <bascule@gmail.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 065EC1A88A0 for <tls@ietfa.amsl.com>; Fri, 22 May 2015 14:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ZUG7JPstypcz for <tls@ietfa.amsl.com>; Fri, 22 May 2015 14:13:12 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3D81A889D for <tls@ietf.org>; Fri, 22 May 2015 14:13:12 -0700 (PDT)
Received: by oihb142 with SMTP id b142so22895304oih.3 for <tls@ietf.org>; Fri, 22 May 2015 14:13:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4JQ86JPHRt3et8NyF9ZagW60for/hRWjAy14D9X6/0g=; b=JPn9bm2EjevpvmJ6Cw7wlTzxHacDTVl8UsMWsOmS8DxxY1YUOgOZCxrm5MmPznUbAo GU9eXr4dcRUjISBjvTTwzFLxncmWjrXU/1ppPyuw5DdRAhshCETlMlnJDB7Akx9VQPZB FoSPvq4apTpTCMXESrYkGxVqFBbzDvsiZx6aZqGFMZbcScPLY96CG9o+fCj0gLPFJ1H4 an5hgMU+lPxLPkzzOdas7holW9JN7VfSD1oirHK0brYgQIkBLlF1sFkzInZNLgLipTog 7svXtJwevslVcFBuGWvOJZGGP9Yzgy+u/jo5KNbAOK62nXJfgQQICyDoOuMtksYMR5sS Q80g==
X-Received: by 10.60.47.34 with SMTP id a2mr8139982oen.48.1432329191795; Fri, 22 May 2015 14:13:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.25.198 with HTTP; Fri, 22 May 2015 14:12:51 -0700 (PDT)
In-Reply-To: <B515FE85-F5C2-4609-A673-936354CEB066@gmail.com>
References: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com> <1432134170.2926.9.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73AB027EED@uxcn10-tdc05.UoA.auckland.ac.nz> <555D90F6.10103@redhat.com> <1432195799.3243.18.camel@redhat.com> <555DBCE6.7080308@redhat.com> <1432206909.3243.45.camel@redhat.com> <555DBF7E.9050807@redhat.com> <1432207863352.27057@microsoft.com> <555DC498.2000109@redhat.com> <1432209104.3243.65.camel@redhat.com> <1432219967072.32353@microsoft.com> <810C31990B57ED40B2062BA10D43FBF5DDDDEB@XMB116CNC.rim.net> <CACsn0c=HuipCG20HGO+uLfBcm+bOEZQFdFdyKWsA1d5D3W0ZCA@mail.gmail.com> <810C31990B57ED40B2062BA10D43FBF5DDF130@XMB116CNC.rim.net> <CAH8yC8mjvXzFm038bXKJr=cnavJ8JGTV4Cufepvv8fXAXp041w@mail.gmail.com> <B515FE85-F5C2-4609-A673-936354CEB066@gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Fri, 22 May 2015 14:12:51 -0700
Message-ID: <CAHOTMVJxjRgL7UqTWsLe+H57Atb_r0FGR6tbH+AS9GFSr+woCg@mail.gmail.com>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b5d45d2adb1460516b22009
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/JSWvU4jEK_DnbS14umAFyQUhBwA>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Fri, 22 May 2015 21:13:14 -0000

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?

Otherwise, all it's doing is making TLS more complicated and vulnerable to
these sorts of downgrade attacks.

-- 
Tony Arcieri