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

"Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu> Wed, 09 March 2011 21:47 UTC

Return-Path: <prvs=2049ffe0e7=jherzog@ll.mit.edu>
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 4DDE23A6778; Wed, 9 Mar 2011 13:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.847
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlsTbobO6wqv; Wed, 9 Mar 2011 13:47:03 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 3B5A13A6AE1; Wed, 9 Mar 2011 13:47:01 -0800 (PST)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p29Llkit009134; Wed, 9 Mar 2011 16:47:46 -0500
From: "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>
To: David McGrew <mcgrew@cisco.com>
Date: Wed, 9 Mar 2011 16:47:45 -0500
Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05
Thread-Index: Acveo6B1edHPaUNbQbaRUiX8Q0yc1A==
Message-ID: <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu>
References: <D858A225-D1D1-497D-BA40-A66D3F55AD57@cisco.com> <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <AA323705-436C-4B71-8B51-D2CA9E4E140C@cisco.com> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <FFD02A42-A10C-4AE7-A763-5C2D1E1DFADA@ll.mit.edu> <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com>
In-Reply-To: <65D56695-894D-458E-A9C4-6DCF6A38F196@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
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: "secdir@ietf.org" <secdir@ietf.org>, "draft-herzog-static-ecdh@tools.ietf.org" <draft-herzog-static-ecdh@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05
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: 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 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:  (781) 981-2356
Technical Staff							fax:    (781) 981-7687
Cyber Systems and Technology Group		email:  jherzog@ll.mit.edu
MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
244 Wood Street    
Lexington, MA 02420-9185