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

"Herzog, Jonathan - 0668 - MITLL" <> Wed, 09 March 2011 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DDE23A6778; Wed, 9 Mar 2011 13:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.847
X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zlsTbobO6wqv; Wed, 9 Mar 2011 13:47:03 -0800 (PST)
Received: from (MX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 3B5A13A6AE1; Wed, 9 Mar 2011 13:47:01 -0800 (PST)
Received: from ( by (unknown) with ESMTP id p29Llkit009134; Wed, 9 Mar 2011 16:47:46 -0500
From: "Herzog, Jonathan - 0668 - MITLL" <>
To: David McGrew <>
Date: Wed, 09 Mar 2011 16:47:45 -0500
Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05
Thread-Index: Acveo6B1edHPaUNbQbaRUiX8Q0yc1A==
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-145--722481887"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-09_08:2011-03-09, 2011-03-09, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103090161
X-Mailman-Approved-At: Wed, 09 Mar 2011 13:48:09 -0800
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Mar 2011 21:47:04 -0000

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 (in conjunction with a NIST- 
> defined KDF).   The "unified cofactor method" is equivalent to the  
> RFC6090 ECDH when the cofactor h=1.  


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
* Full public-key validation: SP800-56A, Section
* Partial public-key validation: SP800-56A: Section
* Key-derivation function... still working on it.


Jonathan Herzog							voice:  (781) 981-2356
Technical Staff							fax:    (781) 981-7687
Cyber Systems and Technology Group		email:
MIT Lincoln Laboratory               			www:
244 Wood Street    
Lexington, MA 02420-9185