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

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 11 April 2014 07:33 UTC

Return-Path: <nmav@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 5F71E1A0107 for <tls@ietfa.amsl.com>; Fri, 11 Apr 2014 00:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.275
X-Spam-Level:
X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-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 i-pEREv5xTGf for <tls@ietfa.amsl.com>; Fri, 11 Apr 2014 00:33:49 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 070051A0106 for <tls@ietf.org>; Fri, 11 Apr 2014 00:33:48 -0700 (PDT)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3B7Xjgd014693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Apr 2014 03:33:45 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s3B7XhsI023164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2014 03:33:44 -0400
Message-ID: <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Alyssa Rowan <akr@akr.io>
Date: Fri, 11 Apr 2014 09:33:42 +0200
In-Reply-To: <5346FEDE.9000909@akr.io>
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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0Bhruq-WNKyjaL-LH5KFcVYreC0
Cc: tls@ietf.org
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:33:50 -0000

On Thu, 2014-04-10 at 21:28 +0100, Alyssa Rowan wrote:

> > And how does this affect an ephemeral key exchange?
> 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.

> Curve25519 was designed _specifically_ so that it can use a lovely,
> extremely fast, constant-time Montgomery ladder: if you're not using
> that, frankly, you're doing it wrong. (Section 5 of the draft already
> addresses that, on my reading.)

I never questioned that, it will be very appropriate when one can use it
with static keys (i.e., ECDH - which are not in this draft). My comment
is for the existing draft that uses the curve for an ephemeral key
exchange, and were directed to the overplay of the relevance of constant
time (as you do here) without understanding whether it is relevant for
the threats on the protocol under discussion. So to recap, being
constant time is a good thing, but not very relevant for ECDHE.

regards,
Nikos