[Cfrg] comments on safecurves draft and goals

David McGrew <mcgrew@cisco.com> Tue, 14 January 2014 21:46 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 88B301AE008 for <cfrg@ietfa.amsl.com>; Tue, 14 Jan 2014 13:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.039
X-Spam-Level:
X-Spam-Status: No, score=-15.039 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.538, 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 etx0N-QdzmWA for <cfrg@ietfa.amsl.com>; Tue, 14 Jan 2014 13:46:36 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 79CB41AE22B for <cfrg@irtf.org>; Tue, 14 Jan 2014 13:46:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2684; q=dns/txt; s=iport; t=1389735984; x=1390945584; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=zHzy0K1O5jSJSg3vad8rJhuIFQ4r2Mep40+NsLBuaIg=; b=AKjDNhNfkYSJPfYCChgURQ7W57n6m0yNzKQ6oS2fnD2l4Di5gxxcv2SS M3HNapUsduK2QESuUrNjMWNKh+P1eyhw7kRm+kCUuQWKedC9uynbPDh31 vZYX5X2LQXgyHTTY+n1IcFojPipcuD0IDTqGpW4hPeB7+N5jgLaUSVgqV c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjwFAHOv1VKtJXHB/2dsb2JhbABagwu7eoEYFnSCZEABPBYYAwIBAgE/DA0BBwKIAMQFF48HhD4BA4lFjlmGRYtQg0se
X-IronPort-AV: E=Sophos;i="4.95,659,1384300800"; d="scan'208";a="297284864"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 14 Jan 2014 21:46:23 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8914.cisco.com [10.117.10.229]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0ELkNIU015451; Tue, 14 Jan 2014 21:46:23 GMT
Message-ID: <52D5B02F.1070103@cisco.com>
Date: Tue, 14 Jan 2014 16:46:23 -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: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] comments on safecurves draft and goals
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: Tue, 14 Jan 2014 21:46:37 -0000

Hi Watson,

I am glad that you started the process of generating an RFC that 
introduces some improved ECC techniques; thanks for doing this.   I want 
to get you some high level feedback, speaking as an RG member, not an RG 
chair.

I think that CFRG should support this work, either by having it become 
an RG draft, or through ongoing review and coordination with the IETF 
Securiy Area.

What would have the most positive impact is a draft that is something 
like RFC609 for Montgomery and/or Edwards curves, which includes:

- complete descriptions for all relevant algorithms (including things 
like octet/integer conversions), and guidance about implementation 
techniques (especially important considering resistance to side channel 
attacks),

- stable normative references for all algorithms,

- definitions and references for mathematical things that a typical 
software or hardware engineer would not know about,

- a description of what interoperability is possible,

- a rationale that explains the design choices, and summarizes the 
security and provides references to appropriate security analyses, and

- a section on intellectual property, which describes what is known 
about the IPR situation.   Of course, the IETF IPR disclosure rules 
apply, so the IETF process for patents will apply.

It might make sense to borrow some of the structure (and perhaps even 
text, such as octet conversions and ECDH) from RFC6090.   I can provide 
you with the source XML if you want.

Ideally, there should be a section on "implementation experience", which 
provides feedback from multiple implementers.

I would guess that this work is something that Dan and Tanja are willing 
to contribute to, say by allowing us to use some of the text (including 
the excellent list of references) on the safecurves site.

A good way to think about this work is: it should provide enough 
information that someone can implement the primitives, and will be 
guaranteed interoperability with someone else's independent 
implementation.   It should provide such a good a self-contained 
rationale for the design and its security that someone who works for a 
vendor or an end-user could use it to justify adopting this 
technology.   And t should enable an implementer to understand the IPR 
landscape surrounding their implementation.

I hope that it doesn't seem like I am raising the bar to make your work 
harder; that is certainly not my goal.   What I am going for is: having 
this work make the biggest and most positive impact.

I saw from your recent note that you have a new version in the works; 
that's great.

David