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 > . >
- [Cfrg] tentative agenda for CFRG at IETF 89 David McGrew
- Re: [Cfrg] tentative agenda for CFRG at IETF 89 Robert Ransom
- Re: [Cfrg] tentative agenda for CFRG at IETF 89 David McGrew
- Re: [Cfrg] tentative agenda for CFRG at IETF 89 Robert Ransom
- [Cfrg] Citing specs in specs Paul Hoffman
- Re: [Cfrg] Citing specs in specs Watson Ladd
- Re: [Cfrg] Citing specs in specs Paul Hoffman
- Re: [Cfrg] tentative agenda for CFRG at IETF 89 David McGrew
- Re: [Cfrg] Citing specs in specs Paul Lambert
- Re: [Cfrg] Citing specs in specs Watson Ladd
- Re: [Cfrg] Citing specs in specs Paul Lambert
- Re: [Cfrg] Citing specs in specs Paul Lambert
- Re: [Cfrg] Citing specs in specs Paul Lambert
- Re: [Cfrg] Citing specs in specs S Moonesamy
- Re: [Cfrg] Citing specs in specs Watson Ladd
- Re: [Cfrg] Citing specs in specs Jon Callas
- Re: [Cfrg] [TLS] Citing specs in specs David McGrew
- Re: [Cfrg] Citing specs in specs Paul Lambert
- Re: [Cfrg] Citing specs in specs Watson Ladd
- Re: [Cfrg] Citing specs in specs Paul Lambert
- Re: [Cfrg] Citing specs in specs Watson Ladd
- Re: [Cfrg] [TLS] Citing specs in specs David McGrew
- Re: [Cfrg] [TLS] Citing specs in specs Paul Lambert
- Re: [Cfrg] [TLS] Citing specs in specs Watson Ladd