Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

Alyssa Rowan <akr@akr.io> Fri, 11 April 2014 07:53 UTC

Return-Path: <akr@akr.io>
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 BCCD11A041E for <tls@ietfa.amsl.com>; Fri, 11 Apr 2014 00:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.881
X-Spam-Level:
X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 n6rCWLZc_Rkb for <tls@ietfa.amsl.com>; Fri, 11 Apr 2014 00:53:45 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id D8E111A041D for <tls@ietf.org>; Fri, 11 Apr 2014 00:53:44 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com>
References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <CACsn0cmFLO2n8d-FVVb4wu=G5T88E7rRd8b=eYo-1uMZnMxkOQ@mail.gmail.com> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <CACsn0ckyaGO9hqn7pDVE2VR-TWs5v+Y6NsnCqCvrwFGyUGfZ3A@mail.gmail.com> <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> <5346FEDE.9000909@akr.io> <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Fri, 11 Apr 2014 08:53:37 +0100
CC: tls@ietf.org
Message-ID: <72d7c28c-0022-497a-b5ca-3d36a6727e39@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jbSi8y_dtz1aJKODWJtAXREiK2Y
Subject: Re: [TLS] Curve25519 in TLS and Additional Curves 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, 11 Apr 2014 07:53:45 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11 April 2014 08:33:42 BST, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>> Assuming all side-channel attacks require repetition seems like the
>> kind of rather dangerous thinking that has bought TLS very unpleasant
>> surprises in the past. We've had quite enough of those already, I think.
>Could you elaborate on how to achieve repetition on a protocol that runs
>only once with the same key? I find your argumentation hard to follow.

Perhaps you misunderstand. Naïvely assuming that every dangerous side-channel attack absolutely needs amplification via repetition is, I feel, optimistic (or, depending on your point of view, pessimistic).

(And if I ever develop such a one-shot attack, I shall name it something like #yolo, because cute attack names are in vogue.)

That's the kind of thinking that got us 20:20 hindsight gems like '[this timing attack] is not believed to be large enough to be exploitable'. Please let's be more careful.

Using good Curve25519 implementations gives us the opportunity to eliminate potential side-channels. Don't waste that opportunity.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJTR5+BGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t69IgQALHjPUyvVhmPWiFH1V3MA1j0RZQBNT+zpguRmby9fp/Vi2VHdQDK
R49WKn5Lrtiqm20qELgsGS7lAFS0a0H3twTmZ/p6Cw9BBlOlcpaWU9bxBYvbQgGD
Ch0W4z+Nqz13LeeYy5909/JcQYEQp8YBzqtU/x4pMnlxPxQwicuKQr0KTrrEHRy5
XAW3zbo9XLz8zn2FMNCioHwMuK0zq3LZz4b5zRitotrtKR3KePgWddenr1NY9ooH
A4Fm1D7VEmB9ABcYMefKAPQeMBnVFx906EHYeyGFZ1QqlefmyDDGla/7FBIcbUoA
oiRCcfnj7ZbbkgPun2lPoY2xKhtAvHkkxTeNcZC+5aqEnEZakG6tCWtzZfRuu+oa
utYtTBR6kghlO73EhhSBpnadFCM4+H0h+1n9Wbr6LT5T8ZXYZ3TSglCcUzlsb0s9
7CYSI+BsMz5V4gov/5ulriBq5TKumKcEAXrbumnYjamphqBrscw9F4lRhIaUOFRT
yUA2t4+lNJUrdm28iCzkcZ7b1vF49KlBmFSRmvRYgPQki2PO3u0FDDb714sc5xr/
g3Nat95ZCMjxXGKWREcXg2r0qQcjdAS6xuDaWGblfx+8CThapBknk5PUjm5tgqCg
+AGDLdJ26xfUyFMURgUjM7i3xRP1uT2VjuUmUHuEfD2rX4oXMKjzfoTV
=JeFt
-----END PGP SIGNATURE-----