Re: [secdir] Secdir review of draft-herzog-static-ecdh-05

[David McGrew <[e-mail]>]

Hi Jonathan,

On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote:

>
> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote:
>
>>>>>
>>>>>> 2. Reference [SEC1] is heavily referenced in this document, for  
>>>>>> both a definition of ECDH and specific methods for using ECDH.  
>>>>>> But it would be good to also mention RFC 6090, which is the  
>>>>>> best IETF document describing ECDH.
>>>>>
>>>>> I was not previous aware of this RFC-- my bad. I have added it  
>>>>> as an informative reference, but continued to refer to [Sec1] as  
>>>>> the normative reference for the ECDH operation. Or do you think  
>>>>> that RFC 6090 should be the normative reference?
>>>>
>>>> I would suggesting using RFC 6090 for a normative reference to  
>>>> ECDH if you need such a reference. But I don't believe RFC 6090  
>>>> discusses static-static consideration or issues at all, so for  
>>>> that [Sec1] seems to be the appropriate normative reference.
>>>
>>> I'm a little uneasy with using RFC 6090 as a normative reference  
>>> for ECDH, as my impression is that the rest of CMS uses SEC1 as  
>>> the normative reference. (See RFC 5753.) This may be because RFC  
>>> 6090 is so new, but I'm worried that switching to RFC 6090 as the  
>>> normative reference for ECDH will introduce subtle  
>>> incompatibilities.
>>>
>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation  
>>> (I think), or the use of the SharedInfo/ukm value.
>>>
>>> Given this, do you mind if I keep SEC1 as normative and use RFC  
>>> 6090 as informative?
>>
>> Sure, that's fine.
>
>
> I've thought a little more about this, and change my proposal to:
>
> * Reference RFC 6090 for ECDH in general, but
> * SEC1 for co-factor ECDH, the public-key validation primitives, and  
> the key-derivation function (KDF).
>
> Unfortunately, none of those algorithms in the second bullet are  
> present in RFC 6090. (Though the security considerations of RFC 6090  
> discuss why one would want to validate public keys, it doesn't  
> describe how to do so.)

That's exactly right.  RFC6090 should be referenced for ECDH, but not  
cofactor-ECDH.

I would like to know: why does the draft reference [SEC1] instead of a  
NIST or IEEE standard?  I would strongly prefer to see explicit  
references to the appropriate NIST algorithms and KDFs in this  
document.  That would make it clear that the specification conformed  
to the NIST crypto guidelines, and that is apparently a goal for the  
document.  It mentions Suite B conformance as a motivator, and Suite B  
references the NIST guidelines.  I think the document describes  
something useful, and that it would be more valuable if it referenced  
the NIST specifications.   Probably the easiest way to do this would  
be to add an additional reference, rather than replace the references  
to [SEC1].

Here is some detail on how RFC6090 EDCH can be used to implement  
static-static ECDH as it is defined by NIST SP 800-56A.  RFC6090  
describes how the ECDH protocol it describes can interoperate with the  
ECSVDP-DH primitive.  NIST SP 800-56 defines static-static ECDH using  
a primitive which it calls the "unified cofactor method", the ECC CDH  
primitive in SP800-56 Section 5.7.1.2 (in conjunction with a NIST- 
defined KDF).   The "unified cofactor method" is equivalent to the  
RFC6090 ECDH when the cofactor h=1.  I'll outline the correspondence.   
The "unified cofactor method" is:

Input:
1. (q, FR, a, b{, SEED}, G, n, h): Domain parameters,
2. dA : One’s own private key, and
3. QB : The other party’s public key.
Process:
1. Compute the point P = hdAQB.
2. If P = O, output an error indicator.
3. Z = xP where xP is the x-coordinate of P.

And here is the table of correspondence between parameters:

SP-800-56A   RFC6090
  q             p
  a             a
  b             b
  G             g
  h             1

h is not used in RFC6090; is is the cofactor associated with the  
elliptic curve generator.  when h=1, ECC CDH is equivalent to ECDH

FR is not used in RFC6090; it is an indication of the field  
representation in ANSI X9.63

SEED is not used in RFC6090; it is an indication of how the ECC  
parameters were created

David

>
>
> Any objections?
>
> Thanks.
> -- 
> Jonathan Herzog							voice:  [phone]
> Technical Staff							fax:    [phone]
> Cyber Systems and Technology Group		email:  [e-mail]
> MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
> 244 Wood Street
> Lexington, MA 02420-9185
>
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir