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

David McGrew <mcgrew@cisco.com> Fri, 28 February 2014 15:54 UTC

Return-Path: <mcgrew@cisco.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 4D2BF1A00DE for <cfrg@ietfa.amsl.com>; Fri, 28 Feb 2014 07:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level:
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 PzMB1YzBQI0r for <cfrg@ietfa.amsl.com>; Fri, 28 Feb 2014 07:54:33 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A54821A0836 for <cfrg@irtf.org>; Fri, 28 Feb 2014 07:54:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3612; q=dns/txt; s=iport; t=1393602871; x=1394812471; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+BBF0SWDbAVZGVI9Ccm/+Tr2ZU/cchaVIpmxEHj5jpM=; b=FpJRubJF35F5ApMh5CM3UKNlDsbnQZe1DBAYav92vuwam3sFiGzWSX1P 5dOkjaPzkzUm/qUBYd2YuYSzXcaTeR+d0PVQ1VAFaQNK/Oe7HlXkgkFo3 RVVX9Jg+RSnC0XCOmCn901OcrLZHJUlBEpjvEdh6rSSsIZnvEcXGjtsXg E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAOqwEFOrRDoJ/2dsb2JhbABZgwaEFb4cgRQWdIIlAQEBAwEjDwEFNgoBEAsOCgICBRYLAgIJAwIBAgFFBg0BBQICh20Hql+gaheBKY0sB4JugUkBA4lKiwWDa4ZKi2GDSx4
X-IronPort-AV: E=Sophos;i="4.97,562,1389744000"; d="scan'208";a="107306155"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 Feb 2014 15:54:22 +0000
Received: from [10.0.2.15] (sjc-vpn7-618.cisco.com [10.21.146.106]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1SFsLaV009119; Fri, 28 Feb 2014 15:54:21 GMT
Message-ID: <5310B12E.4070603@cisco.com>
Date: Fri, 28 Feb 2014 10:54:22 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Robert Ransom <rransom.8774@gmail.com>
References: <530FDC7A.4060404@cisco.com> <CABqy+srTqCXjOR4DMNgWyxf2pZ7dwZfWyznhBuJaY5w8VeuR4Q@mail.gmail.com>
In-Reply-To: <CABqy+srTqCXjOR4DMNgWyxf2pZ7dwZfWyznhBuJaY5w8VeuR4Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/LPHQ6LhVjWrSzq2jY61x0OUZSZY
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 15:54:35 -0000

Hi Robert,

On 02/27/2014 10:17 PM, Robert Ransom wrote:
> 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.

That makes your position clear.

>
>
> 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.

Thanks for the offer to contribute here.

>
>> 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.

I am wary of relying on the curve25519 paper as a normative reference.   
Perhaps your goal here is to provide an informational document (the 
draft that you mention above) that offers implementation guidance, 
instead of a normative reference?

David

>
>
> Robert Ransom
> .
>