[secdir] secdir review for draft-mcgrew-fundamental-ecc-03

Tina TSOU <tena@huawei.com> Tue, 06 July 2010 02:29 UTC

Return-Path: <tena@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2B95E3A6991 for <secdir@core3.amsl.com>; Mon, 5 Jul 2010 19:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.827
X-Spam-Status: No, score=-93.827 tagged_above=-999 required=5 tests=[AWL=-4.933, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, J_BACKHAIR_13=1, J_BACKHAIR_23=1, J_BACKHAIR_31=1, J_BACKHAIR_34=1, J_BACKHAIR_46=1, J_BACKHAIR_51=1, J_BACKHAIR_52=1, J_BACKHAIR_56=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id YlXmh96h4fMu for <secdir@core3.amsl.com>; Mon, 5 Jul 2010 19:29:06 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown []) by core3.amsl.com (Postfix) with ESMTP id B6C7E3A6993 for <secdir@ietf.org>; Mon, 5 Jul 2010 19:29:05 -0700 (PDT)
Received: from huawei.com (szxga03-in []) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5400L9Y6W6S2@szxga03-in.huawei.com> for secdir@ietf.org; Tue, 06 Jul 2010 10:28:54 +0800 (CST)
Received: from huawei.com ([]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L54009BY6W6JQ@szxga03-in.huawei.com> for secdir@ietf.org; Tue, 06 Jul 2010 10:28:54 +0800 (CST)
Received: from z00147053k ([]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5400I5J6W6WS@szxml04-in.huawei.com> for secdir@ietf.org; Tue, 06 Jul 2010 10:28:54 +0800 (CST)
Date: Tue, 06 Jul 2010 10:28:54 +0800
From: Tina TSOU <tena@huawei.com>
To: secdir@ietf.org
Message-id: <4F1C2535C6A94BD4A5F5E313FB245851@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: multipart/alternative; boundary="Boundary_(ID_hK2qFfuSrhbVIyTP5dax7Q)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [secdir] secdir review for draft-mcgrew-fundamental-ecc-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 02:29:08 -0000


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other comments.


1. First sentence: Should >are< rather be >were< ?


2. Introduction (p.2): I would insert the word >finite< before >fields<.

3. Introduction (p.4): >ECDH< should be replaced by >Elliptic Curve Diffie-Hellman (ECDH) <.

Mathematical Background

4. Mathematical Background (p.1): Should >is< rather be >are< ? The same holds in Sec.~2.2 (p.1).

5. Sec.~2.2 (p.3): The term >g< is undefined. Hence, >g^N< should be replaced by >a^N<. The same holds for >Note that a^M is equal to g^ (M mod R)< in (p.9).

6. Sec.~2.3 (p.2):  From this description, it appears to me that all elements in Z_p can perform division operation. However, only non-zero elements, namely elements in the set 

Z_p^* = Z_p-{0}

can perform the division operation. Moreover, all the mathematical operations over Z_p are in the sense of mod p. In addition, a prime number p is called the characteristic of a field, if 1+…+1=0 (add p times); in this case F_q contains the prime field F_p, where q=p^n, n>=1. So I think the definition of the F_p lacks precision.

Elliptic Curve Groups

7. Elliptic Curve Groups (p.1): I think the last sentence is too abstract to understand. More precisely, the elliptic curve satisfies the equations,



when the characteristic of the field is 2 and 3, respectively.

       8. Elliptic Curve Groups (p.3): The first sentence says that >when both points are the point at Infinity<. Maybe such statement is not accurate enough due to the fundamental fact that each elliptic curve abelian group has only one infinity, i.e., the identity element.

       9. Sec.~3.1 (p.2): It seems to me that the projection space representation >x=X/Z mod p , y=Y/Z mod p< is a special case of x=X/Z^{c_1} mod p and y=Y/Z^{c_2} mod p when both c_1 and c_2 are equal to 1. If so, should it be clearly explained ?

       10. Sec.~3.3.1: I would simply state the reason for the non-zero discriminant, namely, to ensure that the elliptic curve is chosen to be a non-singular one, i.e., it has no self intersections or cusps.

Elliptic Curve Diffie-Hellman (ECDH)

       11. Elliptic Curve Groups (p.1): >an arbitrary cyclic group<  instead of >an arbitrary mathematical group< ?

Elliptic Curve ElGamal Signatures

       12. Sec.~5.1 (p.1): Insert >Galois< before >field GF(2^w)<.

       13. Sec.~5.3 (p.2): Why not denote the generator >alpha< as >g< for consistency in this draft ?

       14. Sec.~5.3.2 (4): As the symbol >*< denotes the scalar multiplication, why use such a symbol in Sec.~2.2 to represent the addition operation in a group ? Needs to be modified ?

       15. Sec.~5.3.3 (p.1): Insert >the generator g, the group order q< before >the public key Y< in that these two parameters must know in advance before the signature verification procedure.

       16. Sec.~5.3.2 (1): Should >0<s_1<q< be replaced by >s_1 in Z_q< for consistency ? The same holds for >0<s_2<q< and the sentence in Sec.~5.4.3 (1).

       17. Sec.~5.3.2 (3): As mentioned above, the symbol >*< in the equation 

>R'=alpha^{u_1} * Y^{u_2}< represents the addition operation of two points on the elliptic curve; while in >u_2=s_1 * s_2 mod q<, it means the scalar multiplication operation.

       18. Sec.~5.6 (p.2): In the equations >A=m< and >m=-r*z+s*k (mod q)<, does the symbol m represent a message digest ? If so, I think m should be replaced by h(m), although the hash function is not necessary here. If not, it should be transformed to an integer since it has been defined to be a bit string in Sec.~5.2. The same holds for the equation >m*s=-r*s*z+k (mod q)<.

Converting between integers and octet strings

19. the title >Converting between integers and octet strings<, why not >Converting between Integers and Octet Strings< for consistency ? The same goes for other titles and subtitles.

Security Considerations 
       20. Sec.~10.1 (p.3): I think it is necessary to explain the physical meaning of the cofactor and the reason that a number of attacks are possible against ECDH when the cofactor is not equal to 1.


B. R.