Re: [Cfrg] revised requirements for new curves

Manuel Pégourié-Gonnard <mpg@elzevir.fr> Mon, 08 September 2014 16:28 UTC

Return-Path: <mpg@elzevir.fr>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD81A889F for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 09:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652] 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 0aDx_qV5tgKe for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 09:28:55 -0700 (PDT)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCAB1A8877 for <cfrg@irtf.org>; Mon, 8 Sep 2014 09:28:55 -0700 (PDT)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 845A616148 for <cfrg@irtf.org>; Mon, 8 Sep 2014 18:28:53 +0200 (CEST)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id D38C7290E9 for <cfrg@irtf.org>; Mon, 8 Sep 2014 18:28:51 +0200 (CEST)
Message-ID: <540DD943.1040508@elzevir.fr>
Date: Mon, 08 Sep 2014 18:28:51 +0200
From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= <mpg@elzevir.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <D0333B6F.2C8CF%kenny.paterson@rhul.ac.uk> <767661cb458e2aaadb9967a0dd15d542@mail.gmail.com> <540DBD7D.6080600@elzevir.fr> <CACsn0ckiQehupOK=eNQe6jZAXTTjqYLJ6AHDvytQKHcfx29mdQ@mail.gmail.com>
In-Reply-To: <CACsn0ckiQehupOK=eNQe6jZAXTTjqYLJ6AHDvytQKHcfx29mdQ@mail.gmail.com>
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/yxabqr-OExhp9xqVD_WmKW2uT-0
Subject: Re: [Cfrg] revised requirements for new curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 16:28:58 -0000

On 08/09/2014 17:12, Watson Ladd wrote:
> On Mon, Sep 8, 2014 at 7:30 AM, Manuel Pégourié-Gonnard <mpg@elzevir.fr>; wrote:
>> By the way, the TLS curve/point negotiation doesn't allow peers to negotiate the
>> use of different point formats for different curves. That's probably something
>> to bear in mind when discussing point formats.
> 
> I think that is more wrong than right. 

Or maybe just not clear enough, sorry for that. Let me expand a little bit,
assuming Curve25519 (for the sake of the example) is standardised, the CFRG
and/or the TLS WG will have to choose between the following options:

1. Use only short-Weierstrass format for point transmission, for this curve as
well as the others, meaning that no new point format is added, but
implementations have to either convert between representations, or use the
classic code for short Weierstrass arithmetic.

2. Use only Mongtomery-x format with this curve (and maybe other new curves
supporting it, but obviously not with the NIST and Brainpool curves).

3. Allow both formats, with the idea that implementations are free to choose. My
point was, this is not as good an idea as it might seem, since currently an
implementation has no way of saying "I support the short Weierstrass point
format(s) with the NIST/brainpool curves, and Montgomery-x with Curve25519, but
not short Weierstrass with Curve25519 (since I want to use the Montgomery ladder
but didn't implement conversion between short-Weierstrass and Montgomery)".

I'm not saying this is a big issue, just something we might want to keep in
mind. Of course TLS could change its negotiation procedure to negotiate (curve,
point format) pairs instead, but I'm not sure it would be a good thing, esp. if
we want it to be usable before TLS 1.3.

I thought about this while reading djb's email about the fact that the new
curves allow more options, since they can be converted to short Weierstrass
representation. It's entirely correct of course, but it might be good to
restrict that flexibility (options 1 and 2 above).

> Currently all curves are short
> Weierstrass. If we say "curveXYZ means you do this instead, and adjust
> the point formats accordingly", is that really a problem? Certainly
> the Curve25519 in TLS draft didn't think so.
> 
That would be option 2 above, which is not a problem. I was trying to warn about
option 3.

Manuel.