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

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 23 January 2014 08:39 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 962791A02A4 for <tls@ietfa.amsl.com>; Thu, 23 Jan 2014 00:39:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.437
X-Spam-Level:
X-Spam-Status: No, score=-7.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 RlKcYqjJMwnU for <tls@ietfa.amsl.com>; Thu, 23 Jan 2014 00:39:38 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 476E81A0282 for <tls@ietf.org>; Thu, 23 Jan 2014 00:39:38 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0N8daVZ010205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jan 2014 03:39:36 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s0N8dYKR020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2014 03:39:35 -0500
Message-ID: <1390466373.20176.8.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Robert Ransom <rransom.8774@gmail.com>
Date: Thu, 23 Jan 2014 09:39:33 +0100
In-Reply-To: <CABqy+spt7BYqjsqLAkZssGp3aY9M+iLqV+pmyr7ZN-TXmJJpVg@mail.gmail.com>
References: <87ob3456s1.fsf@latte.josefsson.org> <CABqy+spt7BYqjsqLAkZssGp3aY9M+iLqV+pmyr7ZN-TXmJJpVg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
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: Thu, 23 Jan 2014 08:39:39 -0000

On Wed, 2014-01-22 at 13:16 -0800, Robert Ransom wrote:

> * The draft still specifies a big-endian point format.  What is the
> technical benefit of requiring every TLS implementation which uses one
> of the existing efficient, secure implementations of Curve25519
> Montgomery-form scalar multiplication to reverse the byte order of its
> input and output?  (Note that people want to use Curve25519 in TLS
> because of those existing implementations, so deliberately breaking
> compatibility with them seems especially unwise.)

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. 

regards,
Nikos