IETF Logo Mail Archive

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

Robert Ransom <rransom.8774@gmail.com> Thu, 23 January 2014 18:33 UTC

Return-Path: <rransom.8774@gmail.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 8EF5A1A01AB for <tls@ietfa.amsl.com>; Thu, 23 Jan 2014 10:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 Tc_kyUw12iaf for <tls@ietfa.amsl.com>; Thu, 23 Jan 2014 10:33:31 -0800 (PST)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A82601A000A for <tls@ietf.org>; Thu, 23 Jan 2014 10:33:31 -0800 (PST)
Received: by mail-qc0-f178.google.com with SMTP id m20so2959300qcx.23 for <tls@ietf.org>; Thu, 23 Jan 2014 10:33:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gt+nuBxPujwJX8Dp7EXT1yFbe01pJYFMKy/nELT7y/s=; b=DCu7HTn8Wm4FvoG/qffcGhuLH1+4FogJZwM8sCRGRqAfT/PquGiyZEI4pdP1mLzM6c dRjApMqCHD80cmIrmhWbFrIg2mg41gGXM8cu+BxixSBWt5qILXcdQssPCiiVj+znrCJE wN/pzHiUk+6VNs1YfznGeGlezzFIDPNJfF0Fs7ORmE1+6D8GDltS6fBb8nSdx3Qyz5eO uOo8yiUvDY3C0qFiAM2sUEWpTKKjCKX0esEBFZXMycAE0096u/JI9VRzvIfvhEmjtMaX Em9V1vwN1qU75kPNyeF0ysh0vtMPyu/M47anNKBBw7q4w9i86OJ8M65pqqNSSxBfnC/N cCnQ==
MIME-Version: 1.0
X-Received: by 10.140.92.213 with SMTP id b79mr13191626qge.108.1390502010639; Thu, 23 Jan 2014 10:33:30 -0800 (PST)
Received: by 10.229.181.132 with HTTP; Thu, 23 Jan 2014 10:33:30 -0800 (PST)
In-Reply-To: <1390466373.20176.8.camel@dhcp-2-127.brq.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>
Date: Thu, 23 Jan 2014 10:33:30 -0800
Message-ID: <CABqy+sp3Ru+dMLXe=6gaXudSxn8UWhYjvHLAD6Y+QVaU685ZYw@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset="UTF-8"
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 18:33:32 -0000

On 1/23/14, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> 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.

*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?


Robert Ransom

v2.23.0 | Report a Bug | By Email