IETF Logo Mail Archive

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

"Salz, Rich" <rsalz@akamai.com> Fri, 24 January 2014 20:19 UTC

Return-Path: <rsalz@akamai.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 33FCA1A016B for <tls@ietfa.amsl.com>; Fri, 24 Jan 2014 12:19:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.435
X-Spam-Level:
X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 UJ10Ie3mXuhP for <tls@ietfa.amsl.com>; Fri, 24 Jan 2014 12:19:04 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B37DE1A012D for <tls@ietf.org>; Fri, 24 Jan 2014 12:19:04 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 43397284E8; Fri, 24 Jan 2014 20:19:03 +0000 (GMT)
Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 1CFB7284E2; Fri, 24 Jan 2014 20:19:03 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 0936FFE055; Fri, 24 Jan 2014 20:19:03 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.92]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 24 Jan 2014 15:19:02 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Manuel Pégourié-Gonnard <mpg@polarssl.org>, Robert Ransom <rransom.8774@gmail.com>
Date: Fri, 24 Jan 2014 15:19:01 -0500
Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS
Thread-Index: Ac8ZNx8XYOgwxHCuRpaN6ThOHCRoLQACavNg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711EB9F2DB6@USMBX1.msg.corp.akamai.com>
References: <87ob3456s1.fsf@latte.josefsson.org> <CABqy+spt7BYqjsqLAkZssGp3aY9M+iLqV+pmyr7ZN-TXmJJpVg@mail.gmail.com> <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com> <CABqy+sp3Ru+dMLXe=6gaXudSxn8UWhYjvHLAD6Y+QVaU685ZYw@mail.gmail.com> <52E2B937.5080502@polarssl.org>
In-Reply-To: <52E2B937.5080502@polarssl.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <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, 24 Jan 2014 20:19:08 -0000

> While I can see your point, I feel "breaking compatibility" is a bit of an overstatement. Swapping bytes when points are written/read is no difficult task and could be done in the TLS-specific portion of the code before passing the point from/to one of the existing implementations of Curve25519 arithmetic.

Sure, and we could also use the existing ECC point structure and transmit 32 bytes of zero as a fake y value.  It's a slippery slope.
 
The main interest in using this curve is to use the existing implementations for their security and performance benefits and that there is a real benefit to being able to feed directly from the wire into implementations.  On the "other side" the only argument seems to be that this format is what all other protocols do.

So explain to me which "side" is following religious dogma? :)

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

v2.23.0 | Report a Bug | By Email