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, 09 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
- [secdir] Secdir review of draft-herzog-static-ecd… Brian Weis
- Re: [secdir] Secdir review of draft-herzog-static… Brian Weis
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Brian Weis
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Brian Weis
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Stephen Farrell
- Re: [secdir] Secdir review of draft-herzog-static… David McGrew
- Re: [secdir] Secdir review of draft-herzog-static… David McGrew
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Stephen Farrell
- Re: [secdir] Secdir review of draft-herzog-static… David McGrew
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… David McGrew
- Re: [secdir] Secdir review of draft-herzog-static… Sean Turner
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Uri Blumenthal
- Re: [secdir] Secdir review of draft-herzog-static… Sean Turner
- Re: [secdir] Secdir review of draft-herzog-static… Stephen Farrell
- Re: [secdir] Secdir review of draft-herzog-static… Stephen Farrell
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Herzog, Jonathan - 0668 - MITLL
- Re: [secdir] Secdir review of draft-herzog-static… Uri Blumenthal