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

["Herzog, Jonathan - 0668 - MITLL" <[e-mail]>]

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.


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

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?



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