IETF Logo Mail Archive

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

Manuel Pégourié-Gonnard <mpg@polarssl.org> Fri, 24 January 2014 19:04 UTC

Return-Path: <mpg@polarssl.org>
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 DFCFE1A009A for <tls@ietfa.amsl.com>; Fri, 24 Jan 2014 11:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.394
X-Spam-Level:
X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, 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 d_vEHblNObrz for <tls@ietfa.amsl.com>; Fri, 24 Jan 2014 11:04:30 -0800 (PST)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id DFF091A0047 for <tls@ietf.org>; Fri, 24 Jan 2014 11:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=w5X54VA192Zs17VzkL0lmqKDWT/ri8k6UBDYH7yuaig=; b=Rd2DNlhuORw4a0Rv6U0V2eK/CXjpLA19aISImO10r0Z0RrEZkZexgtc34O6zdayzRKDnOIcBE+hfN9av4UpOpiACDMbkFxlNSx9JKz+vyXMZLvq8UyTaQOwXROtb2TOgxyOWtAXbxtBS4wGkTvjFyxj+tOfW+mhiQOuAKiTh0+U=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1W6lwM-0005on-Uj; Fri, 24 Jan 2014 19:57:19 +0100
Message-ID: <52E2B937.5080502@polarssl.org>
Date: Fri, 24 Jan 2014 20:04:23 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.1.1
MIME-Version: 1.0
To: Robert Ransom <rransom.8774@gmail.com>, Nikos Mavrogiannopoulos <nmav@redhat.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>
In-Reply-To: <CABqy+sp3Ru+dMLXe=6gaXudSxn8UWhYjvHLAD6Y+QVaU685ZYw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl)
Cc: Simon Josefsson <simon@josefsson.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 19:04:31 -0000

On 23/01/2014 19:33, Robert Ransom wrote:
> On 1/23/14, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>> An Internet protocol is not typically designed based on the existing
>> implementations limitations and they it is often expected to outlive
>> them. Almost all IETF protocols use the big-endian format for
>> transferring integers, and implementations of these protocols in have
>> already ways to convert these numbers to the native endianess.
> 
> *This* Internet protocol is motivated by the existing implementations
> for Curve25519.  What is the *technical benefit* of deliberately
> breaking compatibility with the implementations which justify this
> protocol's existence?
> 
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.

Of course it does not invalidate your point that existing implementations are an
important motivation for this draft, and that there is no technical benefit to
big endian (if you don't count uniformity with other formats as technical), but
I think it's worth noting that we're not discussing whether using the existing
implementations will be *possible* but only *how easy* it will be.

Manuel.

v2.23.0 | Report a Bug | By Email