Return-Path: 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" To: David McGrew 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: <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu> <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com> <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" , "draft-herzog-static-ecdh@tools.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:47:04 -0000 --Apple-Mail-145--722481887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 9, 2011, at 3:32 PM, David McGrew wrote: > Hi Jonathan, >=20 > On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote: >=20 >>=20 >> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote: >>=20 >>>>>>=20 >>>>>>> 2. Reference [SEC1] is heavily referenced in this document, for =20= >>>>>>> both a definition of ECDH and specific methods for using ECDH. =20= >>>>>>> But it would be good to also mention RFC 6090, which is the =20 >>>>>>> best IETF document describing ECDH. >>>>>>=20 >>>>>> I was not previous aware of this RFC-- my bad. I have added it =20= >>>>>> as an informative reference, but continued to refer to [Sec1] as =20= >>>>>> the normative reference for the ECDH operation. Or do you think =20= >>>>>> that RFC 6090 should be the normative reference? >>>>>=20 >>>>> I would suggesting using RFC 6090 for a normative reference to =20 >>>>> ECDH if you need such a reference. But I don't believe RFC 6090 =20= >>>>> discusses static-static consideration or issues at all, so for =20 >>>>> that [Sec1] seems to be the appropriate normative reference. >>>>=20 >>>> I'm a little uneasy with using RFC 6090 as a normative reference =20= >>>> for ECDH, as my impression is that the rest of CMS uses SEC1 as =20 >>>> the normative reference. (See RFC 5753.) This may be because RFC =20= >>>> 6090 is so new, but I'm worried that switching to RFC 6090 as the =20= >>>> normative reference for ECDH will introduce subtle =20 >>>> incompatibilities. >>>>=20 >>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation =20= >>>> (I think), or the use of the SharedInfo/ukm value. >>>>=20 >>>> Given this, do you mind if I keep SEC1 as normative and use RFC =20 >>>> 6090 as informative? >>>=20 >>> Sure, that's fine. >>=20 >>=20 >> I've thought a little more about this, and change my proposal to: >>=20 >> * Reference RFC 6090 for ECDH in general, but >> * SEC1 for co-factor ECDH, the public-key validation primitives, and =20= >> the key-derivation function (KDF). >>=20 >> Unfortunately, none of those algorithms in the second bullet are =20 >> present in RFC 6090. (Though the security considerations of RFC 6090 =20= >> discuss why one would want to validate public keys, it doesn't =20 >> describe how to do so.) >=20 > That's exactly right. RFC6090 should be referenced for ECDH, but not =20= > cofactor-ECDH. >=20 > I would like to know: why does the draft reference [SEC1] instead of a = =20 > NIST or IEEE standard? No particular reason. Obviously, this was a bad choice on my part. > I would strongly prefer to see explicit =20 > references to the appropriate NIST algorithms and KDFs in this =20 > document. That would make it clear that the specification conformed =20= > to the NIST crypto guidelines, and that is apparently a goal for the =20= > document. It mentions Suite B conformance as a motivator, and Suite B = =20 > references the NIST guidelines. I think the document describes =20 > something useful, and that it would be more valuable if it referenced =20= > the NIST specifications. Probably the easiest way to do this would =20= > be to add an additional reference, rather than replace the references =20= > to [SEC1]. >=20 > Here is some detail on how RFC6090 EDCH can be used to implement =20 > static-static ECDH as it is defined by NIST SP 800-56A. RFC6090 =20 > describes how the ECDH protocol it describes can interoperate with the = =20 > ECSVDP-DH primitive. NIST SP 800-56 defines static-static ECDH using =20= > a primitive which it calls the "unified cofactor method", the ECC CDH =20= > primitive in SP800-56 Section 5.7.1.2 (in conjunction with a NIST-=20 > defined KDF). The "unified cofactor method" is equivalent to the =20 > RFC6090 ECDH when the cofactor h=3D1. =20 [snip] Right: standard ECDH is the same as cofactor ECDH when the cofactor h =3D = 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 =3D 2 or h =3D 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? --=20 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 =20 Lexington, MA 02420-9185 --Apple-Mail-145--722481887 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJrzCCBNIw ggO6oAMCAQICChVM3JYAAAAAIh8wDQYJKoZIhvcNAQEFBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwg Q0EtMTAeFw0xMDA1MjUyMDQ1MzhaFw0xMTA1MjUyMDQ1MzhaMGQxCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIzAhBgNVBAMTGkhl cnpvZy5Kb25hdGhhbi5DLjUwMDExMzA1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 93mr5a6zq6EQsVtIX9BadxwzpjabF8pvDmoMSP/ZhbWrncNJ1j7xiBGcihYqsDaQz9+hJITxi7IM NUx5fnFtOQRHZgkOCLR1URFc0AlJ3Pknv6XoQ4fqPODmSMB882c9l/8AbO7N/27r8n/V0Ip4Rpw8 1qnrDXk6UH/1zHlssGmlVng0RSREuQy98xPxzbLr5cOMWLwHs5OLNYcGv0KlD6rp1DPzJ3qplU/+ 0P2jyYbGyXStJ/h+3Kx5mOWFLB4j8HDyLG90ZHlZjZXo9FrSoFubVJK/mdVzIuXd00Ldl1fCyxhR D9elkpTc7xOLJsEzCCi8Gqo6eQuvz1RH93u3PwIDAQABo4IBlzCCAZMwDgYDVR0PAQH/BAQDAgbA MB0GA1UdDgQWBBRPjG6+CxR6H/o9vyq5PgmW9vmuajAfBgNVHSMEGDAWgBSUWsZYybYmm6AJe6gv ZJDDiQJuKjAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0ExMGIGCCsGAQUFBwEBBFYwVDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0ExMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5sbC5taXQuZWR1LzAMBgNVHRMBAf8E AjAAMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH /4pzAgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwHQYDVR0RBBYwFIESamhlcnpvZ0BsbC5taXQuZWR1MA0GCSqGSIb3DQEB BQUAA4IBAQBI6aoe1c6Glzs3Hh/lIzf2TzmtZSQLl8UZaIFGi0zG0EjsO6wjX6bfv/WizE30OEef 6So76p0dNt7j21lrH+FGaH6r41ggikbkoazNkAePsQk0WPZhmpus1rByNUozK4KMPpzLAynHNd5m POtqoIwDiTEgktLuZ1nwU7bUHmv7BO14dkhLhMOFKRCIi3vqe9rDh9pTYt1YNhQe1fBme6Y5DWLA TxBBqErz05e7rVngKi6yk6j7cqWpiM6L93z2Zq5p9FqACsJHmMwxH/8XFeeXgFf/CKMAIuSZCGFU 29ouEZWL7LLu87SFGm3f/3sLS7xgXei7d/PlXte1HKKdKOCPMIIE1TCCA72gAwIBAgIKFU5e0QAA AAAiIDANBgkqhkiG9w0BAQUFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4g TGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xMB4XDTEwMDUyNTIw NDcxN1oXDTExMDUyNTIwNDcxN1owZDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEjMCEGA1UEAxMaSGVyem9nLkpvbmF0aGFuLkMu NTAwMTEzMDUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtC8sNdkCteQagOVEnQQs4 5uLqsmaOfjqTywNWuvaVj0F8Jsek8bOcuK4rlB1PrBk0Q+s/N4FVcGEn6BEDWRIDFaETVr1jweTE yRUtqngTIvpbpeixV37BcFkVnbV2VrZC5oaa0c0bkxXkuE0lohQS5AIBXQRADEJVnfXIM44yvsmo T7J5rdGwjIg4QJ2YA07po0JkbndcylcjU0zW2Lv432MEZrX/o+T0rraFAhT8A+8De9CIo0LJkXCK cNwk6LwuNKQS0qeezDo5wRiqZaht3ftiAuOImOxN44hxnDa2cHVbOFQ+pevN08gH7d39CVHUbHMC PnuIBoQNu61I2+ItAgMBAAGjggGaMIIBljAOBgNVHQ8BAf8EBAMCBSAwHQYDVR0OBBYEFEuYUJcI JTs8b2SWTJN28DD/qqsNMB8GA1UdIwQYMBaAFJRaxljJtiaboAl7qC9kkMOJAm4qMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTEwYgYIKwYBBQUHAQEE VjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTEwIwYIKwYB BQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUH BDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0l BB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMB CDAdBgNVHREEFjAUgRJqaGVyem9nQGxsLm1pdC5lZHUwDQYJKoZIhvcNAQEFBQADggEBAAmf5m3W 0Di4aQhLS1e2xejG3MQPQJvWL3dHbnHYG+NDVFWcuqyE5t73eb7nV2UyGRVHDt6MyIquedAPPm86 FSPZ6CUGGj5imp9pAu7C+xESBMY4z0k5htK/h5vlSB9X/i3JbXI8KBOioH1QYenMfrvTISmk/+5A BHsMDOpK7//bX66DP+iopoIiWJktY+dfiak7uTZhuYEOmICq4QlP9dDqdPiQGje4Y8xZ45YL6+2I m5GIzuIac/r51YTBuCk+TxTZIITMx+Fr50Ur6s4dOnvApxMR7iZX6oKnmVfXrjFMMQxR1TN5ISUn IoMyID3yCiInqQh6G3WPCAhwa/qG/moxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYD VQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExM IENBLTECChVM3JYAAAAAIh8wCQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMzA5MjE0NzQ1WjAjBgkqhkiG9w0BCQQxFgQUzNnWyYu3Fa6G ZC6ZEEBVPVRzISUwbgYJKwYBBAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMHAGCyqGSIb3DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0xAgoV Tl7RAAAAACIgMA0GCSqGSIb3DQEBAQUABIIBAMn4JQ294yOrM8XgUYLLp6ky6i40fK+1V8Qss+Gt zPhtJ3hfC5dRmHCRgXl488BRZaCfvZIMOx8kMbOvoAfPazqpjQYfdy4pw5R79WG7U41x4GInLalO GKUlPg4fHMnmJO60MTXAr9Ml+I1kw/mIdaT8q0+tAt2hBxJR/r0ezA94K2EBLa72//2rgdpHWsol OBUDjqEVgyhNxPW8CWM0mo/6lwr4ad1mXieKO+rrxnN8ULE7VgUcvWNqQFok8+z0OkERUJudZR4J wlH+O2XkY2bwqfmxMjEI3n9A7Zr0AjM70NbqD2Ng84sQGIhOJQj4cgL0vbMDkQmzEeltFyxH+mAA AAAAAAA= --Apple-Mail-145--722481887--