Re: [Cfrg] tentative agenda for CFRG at IETF 89

Robert Ransom <rransom.8774@gmail.com> Fri, 28 February 2014 03:17 UTC

Return-Path: <rransom.8774@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 8EB081A02B2 for <cfrg@ietfa.amsl.com>; Thu, 27 Feb 2014 19:17:06 -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 lvQOAyg7WCdi for <cfrg@ietfa.amsl.com>; Thu, 27 Feb 2014 19:17:05 -0800 (PST)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3354A1A0381 for <cfrg@irtf.org>; Thu, 27 Feb 2014 19:17:05 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id j7so134078qaq.24 for <cfrg@irtf.org>; Thu, 27 Feb 2014 19:17:03 -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:content-transfer-encoding; bh=q3ylwMLwTA+EKikVEYUx+lP0ClwRxtK4r0syekAj1Ko=; b=yb8pM48l/kbksSsofsIdIqsoO1VOpHPnaAGN1vuAHwd3EEWR4uq/U4Pv3/+dX2E7fN WLzzlpeSTfw4saNbzMSEyfJhs0EGvRRtV4P9k2o/4PcThRfxEegHQPLzUZWVsQZ0fbX2 /qDdMn5who3FLpYwmlRYreNnwfVEFErgBVOito9uP3RKgtrol7DBdW7mU3w344q8X+xV 6vyPxOCPzIs3qAWwALrcgXzsDSb2W0q6Gk+x6QkSYoQpsxvk4NnFb9eT0A1uj4eQ5FwC Rp+az1+hrcoksL46yjInqQW2meLchq0xFDR6jAmcBR9MT16zBdjKoa/Ad3WxqM91bPZt +85A==
MIME-Version: 1.0
X-Received: by 10.224.223.134 with SMTP id ik6mr575221qab.90.1393557423257; Thu, 27 Feb 2014 19:17:03 -0800 (PST)
Received: by 10.140.20.243 with HTTP; Thu, 27 Feb 2014 19:17:03 -0800 (PST)
In-Reply-To: <530FDC7A.4060404@cisco.com>
References: <530FDC7A.4060404@cisco.com>
Date: Thu, 27 Feb 2014 19:17:03 -0800
Message-ID: <CABqy+srTqCXjOR4DMNgWyxf2pZ7dwZfWyznhBuJaY5w8VeuR4Q@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: David McGrew <mcgrew@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/dfBs90s7U5J6BIvtwDkCbw7RvSQ
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] tentative agenda for CFRG at IETF 89
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: Fri, 28 Feb 2014 03:17:06 -0000

On 2/27/14, David McGrew <mcgrew@cisco.com> wrote:

> The TLS WG has asked for the CFRG opinion on ChaCha+Poly1305.    We also
> should be offering an opinion on the new ECC mechanisms.   Some
> questions for you: should we take on draft-ladd-safecurves-03 as an RG
> draft?

I strongly oppose adoption of draft-ladd-safecurves-03 as an RG draft or an RFC:

* In draft-ladd-safecurves-00, the ‘author’ merely copied a pile of
curve equations into an I-D and tried to pass it off as his own useful
contribution.  draft-ladd-safecurves-03 still takes a fundamentally
wrong approach in specifying several specific curves, when what is
needed is a document describing how the whole class of Montgomery and
Edwards curves is currently used and can be used in future
applications.

* It repeatedly claims to specify a ‘standard’ for ECC on those
curves; however, the draft is ‘Informational’, and it specifies point
formats for Curve25519 which are deliberately incompatible with the
existing standard practices among implementations.  Thus, it is
attempting to specify a new ‘standard’ in a non-standards-track
Internet document, in clear defiance of IETF policy.

* It contains several factual inaccuracies.

* It takes a condescending tone toward implementors, while omitting
critical details needed to apply what little information it provides
to other Montgomery and Edwards curves.

* None of the text of the draft explains any aspect of the use of
Montgomery and Edwards curves or any background information in a
useful level of detail.  It is not useful even as a starting point for
an RFC on this topic.

* The author has repeatedly disregarded advice from other RG members
regarding this draft, usually with unnecessary hostility.  I have not
yet seen any reason to believe that he will change his behaviour.  If
he is chosen as the editor of an RG document at this time, I will not
waste my effort on attempting to contribute to it.


I have nearly finished writing a relatively elementary exposition of
the background in abstract algebra and (Weierstrass-form) elliptic
curves needed to properly explain Montgomery and Edwards curves and
their use in cryptography.  I intend to send it to the CFRG mailing
list either tonight or tomorrow for review.  After that, the portion
of a document describing Montgomery and Edwards curves themselves (as
currently used) should be relatively easy.


> Should we recommend its adoption in TLS?

draft-ladd-safecurves is not needed in order to adopt Curve25519 for use in TLS.

Dr. Bernstein's Curve25519 paper specifies the existing standard for
scalar multiplication on Curve25519 in sufficient detail to serve as a
normative reference for RFCs specifying its use in ECDH in IETF
protocols.  I believe that Curve25519 should be recommended for
adoption in TLS, and that a future version of
draft-josefsson-tls-curve25519 (which addresses the comments made on
the TLS list regarding the (current) -04 version) will be suitable for
publication as an RFC.


Robert Ransom