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

[David McGrew <[e-mail]>]

Hi Jonathan,

On Mar 9, 2011, at 1:47 PM, Herzog, Jonathan - 0668 - MITLL wrote:

>
> On Mar 9, 2011, at 3:32 PM, David McGrew wrote:
>
>> 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?
>
> No particular reason. Obviously, this was a bad choice on my part.

"You are lost in a maze of public key cryptography standards, all  
nearly alike"   I've had that feeling before ;-)

>
>
>> 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.
>
> [snip]
>
> Right: standard ECDH is the same as cofactor ECDH when the cofactor  
> h = 1. Granted, this is true for the two Suite B curved (P256 and  
> P384) but not true for all the curved named in FIPS 186-3 / RFC  
> 5480. (For the curves over binary fields, the co-factor can be h = 2  
> or h = 4.) So unless I'm missing something (which is more than  
> likely) I don't think we can use RFC 6090 for both standard ECDH and  
> cofactor ECDH for all curves in FIPS 186-3.

That's right, you're not missing anything.

>
> However, SP800-56A does define cofactor ECDH. So let me propose the  
> following citation scheme:
>
> * ECDH in general: RFC 6090
> * Standard ECDH: RFC 6090
> * Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2
> * Full public-key validation: SP800-56A, Section 5.6.2.5
> * Partial public-key validation: SP800-56A: Section 5.6.2.6
> * Key-derivation function... still working on it.
>
> Thoughts?

That looks good to me.  Let me know if I can help with the KDF.

David

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