[Cfrg] Comments on draft-mcgrew-fundamental-ecc-00

Sean Shen <sshen@huawei.com> Thu, 23 July 2009 07:18 UTC

Return-Path: <sshen@huawei.com>
X-Original-To: cfrg@core3.amsl.com
Delivered-To: cfrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03ED73A6823 for <cfrg@core3.amsl.com>; Thu, 23 Jul 2009 00:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.469
X-Spam-Level: *
X-Spam-Status: No, score=1.469 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVv5xDigOwCe for <cfrg@core3.amsl.com>; Thu, 23 Jul 2009 00:18:56 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BB6193A6817 for <cfrg@irtf.org>; Thu, 23 Jul 2009 00:18:33 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN800KHX44UE2@szxga03-in.huawei.com> for cfrg@irtf.org; Thu, 23 Jul 2009 15:14:54 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN800D8D44U5K@szxga03-in.huawei.com> for cfrg@irtf.org; Thu, 23 Jul 2009 15:14:54 +0800 (CST)
Received: from s00102542 ([10.111.12.128]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN80030744TU9@szxml06-in.huawei.com> for cfrg@irtf.org; Thu, 23 Jul 2009 15:14:54 +0800 (CST)
Date: Thu, 23 Jul 2009 15:14:53 +0800
From: Sean Shen <sshen@huawei.com>
To: mcgrew@cisco.com, cfrg@irtf.org
Message-id: <00b101ca0b65$46ae9750$800c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_m3R+WB9cL6GcbdPYMjRlfw)"
Thread-index: AcoLZUY537JwzYi6Sm+8wuU0jTvsiw==
Subject: [Cfrg] Comments on draft-mcgrew-fundamental-ecc-00
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/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: Thu, 23 Jul 2009 07:18:57 -0000

Hi, David,
Thank you for providing such a document. As a ecc fan, I like this document
very much, :)
I was not able to finish reading the whole document yet, but get a few
comments so far:
#1
section 2.1
When you are discribing "set Zp = { 0, 1, 2, ..., p-1 }", looks like you do
not limit p to be a prime. 
Usually Zn is used for arbitary modular group, Zp refer to modular group
with prime order.
 
#2
section 2.2
By definition, the operation "*" defined on any group have a property of
associative law: (a*b)*c=a*(b*c). 
The operation "*" is called "+" when it also has another good property
called commutative law, i.e. a+b=b+a.
 
#3
section
This document only cover curves over finite fields with Characteristic>3. Is
there a reason for this? I 
imagine becuase Certicom's recent IPR disclosure provide royalty free
license for 3 ECP curves? I don't 
know whether IETF will more recommend ECP curse because of this disclosure,
but I think this is a good 
reason to only describe ECP curves. If it is the reason, might be good to
mention it.  
I took a brief looks at EC groups defined for IKE and TLS:
For IKE and IKEv2:
 RFC2409 and subsequetly IANA defined, 10 EC2N groups (Characteristic=2)
 (http://www.iana.org/assignments/ipsec-registry)
 RFC4753, 3 ECP groups (Characteristic>3)
For TLS:
 RFC4492, 14 EC2N groups, 11 ECP groups
This is a very rough look and can not be considered a survey. 
 
I will keep reading and hope to add more comments.
 
Best,
 
Sean