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

David McGrew <mcgrew@cisco.com> Fri, 11 March 2011 20:31 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 E33EE3A692E; Fri, 11 Mar 2011 12:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.848
X-Spam-Level:
X-Spam-Status: No, score=-109.848 tagged_above=-999 required=5 tests=[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 IpP-Ec+rQq88; Fri, 11 Mar 2011 12:31:29 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A15BB3A68DC; Fri, 11 Mar 2011 12:31:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2025; q=dns/txt; s=iport; t=1299875569; x=1301085169; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=a66fJ/PYcW5gy98TWovQo5geJMRoZWXWBZdLUi7gLsg=; b=E4CeW6YdoXlUNvJbZqBKBElO/tds+QYd3IryJ+Z6JWWmMlsJ3ogkYYLS NLa77pcRv2vOwlICe8oq6pXZJOGCJK4FqQsIcKP8wYd547v9YksrJsTNr FbIcFNSci3ER2CU0eYR7ADd268rWlnjau6K/WqSOJ/3mtK9YAlVhC6X+E w=;
X-IronPort-AV: E=Sophos;i="4.62,305,1297036800"; d="scan'208";a="274968806"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 11 Mar 2011 20:32:49 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2BKWk0F021290; Fri, 11 Mar 2011 20:32:46 GMT
Message-Id: <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>
In-Reply-To: <63667400-81DF-438E-869F-247222DECA18@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: Fri, 11 Mar 2011 12:32:45 -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> <A2B7EC12-25AA-4D0A-ACA3-A5E67C14E596@cisco.com> <63667400-81DF-438E-869F-247222DECA18@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: Fri, 11 Mar 2011 20:31:31 -0000

Hi Jonthan,

On Mar 10, 2011, at 12:41 PM, Herzog, Jonathan - 0668 - MITLL wrote:

>
> On Mar 10, 2011, at 1:12 PM, David McGrew wrote:
>>
>>
>>>
>>> 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.
>
>
> I'd appreciate it, thanks. One of the goals of this draft is to  
> remain as compatible with RFC 5753 as possible, so as to impact  
> implementations as little as possible. RFC 5753, for its part,  
> specifies the KDF in SEC1. And the KDF in SEC1 is just the 'simple  
> hash function construct described in ANSI X9.63'. So, do you think I  
> can cite X9.63 as the normative reference? And if so, what are your  
> thoughts on citing SEC1 as an informative reference for this KDF?  
> SEC1 is, after all, freely available on the web.

Good point.

I hope that the KDF from X9.63 that is referenced in SEC1 is the  
Concatenation Key Derivation Function (Section 5.8.1 of SP800-56A), or  
if not, the ASN.1 Key Derivation Function (Section 5.8.2).   The  
800-56A text on key agreement schemes says that they are based on  
X9.63 algorithms, though it doesn't explicitly mention the KDFs.

David

>
> (Note: I'm still chasing down the ANSI spec to ensure that it does,  
> in fact, match the description in SEC1.)
>
> Thanks.
>
> -- 
> 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
>