Re: [Cfrg] revised requirements for new curves

Watson Ladd <watsonbladd@gmail.com> Mon, 08 September 2014 15:12 UTC

Return-Path: <watsonbladd@gmail.com>
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 E68271A8874 for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 08:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.199
X-Spam-Level:
X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 PJAO07_2F1Tu for <cfrg@ietfa.amsl.com>; Mon, 8 Sep 2014 08:12:04 -0700 (PDT)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36581A886D for <cfrg@irtf.org>; Mon, 8 Sep 2014 08:12:03 -0700 (PDT)
Received: by mail-yk0-f178.google.com with SMTP id 20so90617yks.9 for <cfrg@irtf.org>; Mon, 08 Sep 2014 08:12:03 -0700 (PDT)
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:content-transfer-encoding; bh=Ci0pTuKLMgObXZWs9UH0KvV4E64fytTcfnQZazy2AyM=; b=ofC/1A84ZlL9xZtPmqspk2R6IgYjfrjV9G5EMJxTCulmyK8EL7fR/LBW/Eh1x4/xxx zbX54I6GDgJC0ne4hwYA1WP3UBHX1bl7zJSIUmA2I0yFXI/wnz3n1Mj0RkzdPaLnikBW gL4kSJ8XVM3X2NBHOptzS91t4LK3ACplvOu9X4V+Fy5ElD3Rc7yD/fF2NDPMKKrrTD2T XXfLTQtUcWocfMtXErPXTGg7Ph0nvCLWToXoazjxfEtmbGjXiGSAzCmspa1ZFcHz6rpA P6TQ1J73Z3J3SlGUWZXbjTDf0+rZSJPqG/B1SdLOxy3tjp2ZlFTlV3J0/FkUfJZ9ATAY /wgw==
MIME-Version: 1.0
X-Received: by 10.236.172.161 with SMTP id t21mr43381069yhl.65.1410189123103; Mon, 08 Sep 2014 08:12:03 -0700 (PDT)
Received: by 10.170.207.216 with HTTP; Mon, 8 Sep 2014 08:12:03 -0700 (PDT)
In-Reply-To: <540DBD7D.6080600@elzevir.fr>
References: <D0333B6F.2C8CF%kenny.paterson@rhul.ac.uk> <767661cb458e2aaadb9967a0dd15d542@mail.gmail.com> <540DBD7D.6080600@elzevir.fr>
Date: Mon, 8 Sep 2014 08:12:03 -0700
Message-ID: <CACsn0ckiQehupOK=eNQe6jZAXTTjqYLJ6AHDvytQKHcfx29mdQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= <mpg@elzevir.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/2A6afyZ9WBFFceJDLocV2Q_cOHg
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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 15:12:05 -0000

On Mon, Sep 8, 2014 at 7:30 AM, Manuel Pégourié-Gonnard <mpg@elzevir.fr>; wrote:
> On 08/09/2014 15:49, William Whyte wrote:
>> IN1: I don't understand how a curve could be incompatible with a TLS RFC. A
>> new curve would be a new ciphersuite: to support a new curve, you reserve a
>> ciphersuite identifier and define behavior for that ciphersuite identifier.
>
> I guess you mean a NamedCurve identifier (RFC 4492 sec. 5.1.1) rather than a
> ciphersuite identifier. Currently, ciphersuites only specify the high-level
> mechanism (ECDH(E), ECDSA), not the specific curve(s) used by this mechanism.
> (There is a draft for including curve selection in the ciphersuite identifier,
> but for now it's only a draft). And possibly some new ECPointFormat (sec 5.1.2)
> in addition, if the new curves support other representations than short
> Weierstrass, and the decision is made to allow those representations on the wire
> (rather than to force conversion to short Weierstrass).
>
> 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. 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.

Sincerely,
Watson Ladd

>
> Manuel.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin