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

David McGrew <mcgrew@cisco.com> Thu, 10 March 2011 18:10 UTC

Return-Path: <mcgrew@cisco.com>
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 E65C43A6A50; Thu, 10 Mar 2011 10:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.973
X-Spam-Level:
X-Spam-Status: No, score=-109.973 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100]
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 Y1b7e02LvbJF; Thu, 10 Mar 2011 10:10:51 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3FAE33A6B3B; Thu, 10 Mar 2011 10:10:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=5253; q=dns/txt; s=iport; t=1299780727; x=1300990327; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=QP+LRxO/hvnxyufBtmv410uTy9KJXC78Qibvamdo5d0=; b=KR4L+lCp1/mipm60q8qgzw9/rkQJaKGVvQuhnhjcJUgfUcu87Poa+o8r SVLPvLyELp/wdG+RnSB6r4HTyZIzgcjnuYZe9fpFVtNdH6ix8dSP+fMfh Tl0MaxcS2+blSLdXgWFhD/FHVi++M1jVL9zH6F5wR/wFzcs92TK7GTX4c M=;
X-IronPort-AV: E=Sophos;i="4.62,297,1297036800"; d="scan'208";a="666326303"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2011 18:12:07 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p2AIC6bI006505; Thu, 10 Mar 2011 18:12:06 GMT
Message-Id: <A2B7EC12-25AA-4D0A-ACA3-A5E67C14E596@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>
In-Reply-To: <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 10 Mar 2011 10:12:05 -0800
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> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu>
X-Mailer: Apple Mail (2.936)
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: Thu, 10 Mar 2011 18:10:56 -0000

Hi Jonathan,

On Mar 9, 2011, at 1:47 PM, Herzog, Jonathan - 0668 - MITLL wrote:

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

"You are lost in a maze of public key cryptography standards, all  
nearly alike"   I've had that feeling before ;-)

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

That's right, you're not missing anything.

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

That looks good to me.  Let me know if I can help with the KDF.

David

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