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

David McGrew <mcgrew@cisco.com> Thu, 22 July 2010 22:58 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580F93A6A70 for <secdir@core3.amsl.com>; Thu, 22 Jul 2010 15:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.799
X-Spam-Level:
X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-3.800, BAYES_50=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, J_BACKHAIR_13=1, J_BACKHAIR_23=1, J_BACKHAIR_31=1, J_BACKHAIR_34=1, RCVD_IN_DNSWL_HI=-8]
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 CK2bb74S-eTE for <secdir@core3.amsl.com>; Thu, 22 Jul 2010 15:58:36 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F22223A6A6F for <secdir@ietf.org>; Thu, 22 Jul 2010 15:58:35 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYFABRqSEyrR7Hu/2dsb2JhbACBRJ4hcacjmwuCb4JHBIQAhFk
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Jul 2010 22:58:53 +0000
Received: from stealth-10-32-254-212.cisco.com (stealth-10-32-254-212.cisco.com [10.32.254.212]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6MMwp14001615; Thu, 22 Jul 2010 22:58:51 GMT
Message-Id: <943F9DC0-7E21-49E2-932F-6C14C09EAD79@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: "william.polk@nist.gov Polk" <william.polk@nist.gov>, Tina TSOU <tena@huawei.com>
In-Reply-To: <4C3BAE48.1070401@vigilsec.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-18-884620603
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 22 Jul 2010 15:58:51 -0700
References: <4C3BAE48.1070401@vigilsec.com>
X-Mailer: Apple Mail (2.936)
Cc: Margret Salter <msalter@restarea.ncsc.mil>, "Kevin M. Igoe" <kmigoe@nsa.gov>, secdir@ietf.org
Subject: Re: [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: Thu, 22 Jul 2010 22:58:38 -0000

Hi Tina,

thanks for your comments on the draft.

On Jul 12, 2010, at 5:07 PM, Russ Housley wrote:

> I did not see you as recipients on this note.  Forwarding ...
>
> Russ
>
> - - - - - - - - -
>
> Hi,
> 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.
>
> Abstract
> 1. First sentence: Should >are< rather be >were< ?

Changed.

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

Changed.

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

Changed.

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

Changed.

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

Changed.

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

I think this explanation of finite fields is appropriate for this  
note.  It is not intending to be a general introduction to finite  
fields, but instead to provide only the background needed to  
understand the rest of the note.  The statement " When p is a prime  
number, then the set Zp, with the addition, subtraction,  
multiplication and division operations, is a finite field with  
characteristic p" is correct and precise.

I suggest that the section heading be changed from "Finite Fields" to  
"The Finite Field Fp".


> 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,
> y^2+cy=x^3+ax+b,
> y^2=x^3+ax^2+bx+c,
> when the characteristic of the field is 2 and 3, respectively.

I disagree.  If the paragraph is difficult for the non-mathematician  
to understand, I don't think adding more math will help.  Besides, the  
definitions here match [M1985] and [K1987].

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

I disagree that this needs to be changed; it is clear as it stands.  I  
don't see how it could be made more accurate, since inserting "equal  
to" before "the point at infinity" would be inappropriate in a  
definition about what it means for points to be equal.

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

The exposition in this section matches the reference, which is one of  
the goals of the draft.

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

I disagree; the discriminant is not used anywhere in the draft, and is  
only mentioned for consistency of the elliptic curve group  
definition.  Curve parameter generation is out of scope for this  
draft, and so the target audience has no need for the information.	

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

Changed; I verified that [M1983] mentions cyclic groups as well.

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

I added "finite" instead of "Galois" since the latter term is not  
defined in the document.

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

In order to closely follow the original references.

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

The draft uses multiplicative notation throughout for consistency with  
early references; see S 2.2 par 2.

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

Changed.

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

I assume that you mean S 5.3.3..  This change would be wrong because  
it would mistakenly include 0.  Besides, the sentence in the draft  
matches that in the reference [FIPS186].

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

The draft uses multiplicative notation throughout for consistency.


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

S 5.6 is non-normative rationale, and the equations exactly match the  
references.  The lack of a hash function is already explained: "No  
hash function is shown in the above equations, but as described in  
Section 10.4, a hash function should be applied to the message prior  
to signing in order to prevent existential forgery attacks."

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

Changed.

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

The term "cofactor" was introduced after 1994 and thus is not in the  
normative part of the draft. I am unsure of what explanation you think  
would be appropriate, because the definition is straightforward.  I  
disagree that detailed descriptions of the attacks are required in  
this draft.  Parameter generation is declared out of scope, cofactor=1  
is recommended, and references are provided for the attacks  
mentioned.  The intended audience is implementers, not cryptographers  
generating new elliptic curve groups.

Kevin provided a good definition of cofactor suitable for Section 2,  
if we can find a pre-1994 reference:

       in cryptographic applications, the group G typically has only a
       finite number of elements, and the ratio between the number of
       elements in G (denoted by #G) and the number of elements in the
       cyclic subgroup H (denoted by #H) is called the cofactor of H  
in G,
       that is cofactor = #G/#H. Note that the cofactor is always  
greater
       than or equal to 1, and the cofactor is 1 if and only if H = G. A
       fundamental result of group theory is that the cofactor is always
       an integer.

regards,

David

>
>
> B. R.
> Tina
> http://tinatsou.weebly.com/contact.html
> <Attached Message Part.txt>