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

Uri Blumenthal <uri@MIT.EDU> Tue, 15 March 2011 20:26 UTC

Return-Path: <uri@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 40B8A3A6E44; Tue, 15 Mar 2011 13:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_OBFU_ALL=0.751]
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 1C90LM7IaovT; Tue, 15 Mar 2011 13:26:12 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 0700F3A6A8B; Tue, 15 Mar 2011 13:26:11 -0700 (PDT)
X-AuditID: 12074424-b7b0bae000000a05-c7-4d7fcbb885ec
Received: from mailhub-3.mit.edu ( [18.9.21.44]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id DC.2B.02565.8BBCF7D4; Tue, 15 Mar 2011 16:27:36 -0400 (EDT)
Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by mailhub-3.mit.edu (8.13.8/8.9.2) with ESMTP id p2FKRZYh005498; Tue, 15 Mar 2011 16:27:36 -0400
Received: from webmail-8.mit.edu (WEBMAIL-8.MIT.EDU [18.9.23.18]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id p2FKSsfM014965; Tue, 15 Mar 2011 16:28:54 -0400 (EDT)
Received: from webmail-8.mit.edu (webmail-8.mit.edu [127.0.0.1]) by webmail-8.mit.edu (8.13.8) with ESMTP id p2FKRTEw002007; Tue, 15 Mar 2011 16:27:29 -0400
Received: (from nobody@localhost) by webmail-8.mit.edu (8.13.8/8.13.8/Submit) id p2FKROcF002002; Tue, 15 Mar 2011 16:27:24 -0400
X-Authentication-Warning: webmail-8.mit.edu: nobody set sender to uri@mit.edu using -f
Received: from c-24-63-227-189.hsd1.ma.comcast.net (c-24-63-227-189.hsd1.ma.comcast.net [24.63.227.189]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Tue, 15 Mar 2011 16:27:24 -0400
Message-ID: <20110315162724.dv4j170hkw8oooo0@webmail.mit.edu>
X-Priority: 3 (Normal)
Date: Tue, 15 Mar 2011 16:27:24 -0400
From: Uri Blumenthal <uri@MIT.EDU>
To: "Herzog, Jonathan - 0668 - MITLL" <jherzog@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> <29C1F1D5-6EF0-4055-BA88-03F03E3F0A84@ll.mit.edu> <A2B7EC12-25AA-4D0A-ACA3-A5E67C14E596@cisco.com> <63667400-81DF-438E-869F-247222DECA18@ll.mit.edu> <7EA8F35D-5D31-472E-BE37-3789470D059A@cisco.com> <CEC0B26E-57CD-400E-8B2C-A31413C4EA2C@ll.mit.edu> <AC6A0275-B484-45F5-B23A-2D0E6DEF50E6@ll.mit.edu>
In-Reply-To: <AC6A0275-B484-45F5-B23A-2D0E6DEF50E6@ll.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)
X-Brightmail-Tracker: AAAAAReea6k=
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-herzog-static-ecdh@tools.ietf.org" <draft-herzog-static-ecdh@tools.ietf.org>, "secdir@ietf.org" <secdir@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: Tue, 15 Mar 2011 20:26:13 -0000

Without diving into the details of various KDF and their cryptographic 
soundness
- I think the proposal to cite X9.63 as normative and SEC1 as informative is
good.

Thanks!
--
<Disclaimer>

Quoting "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>du>:
> On Mar 11, 2011, at 4:13 PM, Herzog, Jonathan - 0668 - MITLL wrote:
>> On Mar 11, 2011, at 3:32 PM, David McGrew wrote:
>>>
>>> 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).
>>
>>
>> Mostly 'yes,' but just enough 'no' to be a real problem for us. Both 
>> the KDF in SEC1/X9.63 and the KDFs in 800-56A take the Diffie 
>> Hellman secret and some Other Stuff, and produce keying material as 
>> output.  But they are not the exact same KDF. From SP 800-56A, 
>> Appendix A ("Summary of Differences between this Recommendation and 
>> ANS X9 Standards"):
>>
>> [Begin quote]
>>
>> 8.	Regarding the key derivation function (KDF):
>>
>> a. This recommendation specifies two Approved KDFs, the 
>> concatenation KDF specified in Section 5.8.1 and the ASN.1 KDF 
>> specified in Section 5.8.2. Other key derivation methods may be 
>> temporarily allowed for backward compatibility. These other 
>> allowable methods and any restrictions on their use will be 
>> specified in FIPS 140-2 Annex D.
>>
>> b. ANS X9.42 provides a concatenation KDF and an ASN.1 KDF, while 
>> ANS X9.63 provides only the concatenation KDF. However, the Approved 
>> KDFs of this Recommendation require that the counter appears before 
>> the shared secret as input to the hash function, whereas the ANSI 
>> KDFs place the counter after the shared secret
>>
>> c. The Approved KDFs in this Recommendation require the input of the 
>> identifiers of the communicating parties; such information is not 
>> required in ANS X9.42 and X9.63.
>>
>> d. In this Recommendation, the shared secret is zeroized after a 
>> single call to a key derivation function, before the key agreement 
>> scheme releases any portion of the DerivedKeyingMaterial for use by 
>> relying applications.. The ANS X9.42 and X9.63 standards do not 
>> indicate when the shared secret needs to be zeroized. An implication 
>> of this Recommendation?s requirement concerning zeroization is that 
>> all of the keying material directly derived from the shared secret 
>> must be computed during one call to the KDF.
>>
>> [End quote]
>>
>> Point (d) is not an issue for this discussion, and point (a) is just 
>> informative. But points (b) and (c) are both show-stoppers. Point 
>> (b) says that SEC1/X9.63 and SP 800-56A disagree on how to turn the 
>> inputs into keying material. Point (c) says that they disagree on 
>> what the Other Stuff must contain. Specifically, SP 800-56A requires 
>> that the Other Stuff contain:
>>
>> * ID of the algorithm,
>> * ID of the sender,
>> * ID of the receiver,
>> * Sender randomness (optional), and
>> * Receiver randomness (optional).
>>
>> SEC1 places no restriction on the Other Stuff. But RFC 5753 says 
>> that the Other Stuff must be the DER encoding of an 
>> ECC-CMS-SharedInfo structure, which contains:
>>
>> * ID of the algorithm,
>> * Sender randomness (optional), and
>> * Length of output key (optional).
>>
>> So unless I'm wrong (again, more than likely) the SEC1/X9.63 and SP 
>> 800-56A KDFs are not compatible. And in fact, we can't switch to the 
>> SP 800-56A KDFs without introducing some tricky incompatibilities 
>> with RFC 5753. (Implementors would have to implement one KDF for 
>> ephemeral-static ECDH and a different one for static-static ECDH).
>>
>> Given this, what do people think of citing X9.63 for the KDF? And 
>> about citing SEC1 as an informative reference so that people can 
>> find the KDF without having to buy an ANSI standard?
>
> I was advised to submit an updated draft over the weekend, even if 
> some issues were still up in the air. So, 
> draft-herzog-static-ecdh-06.txt has been submitted and is awaiting 
> manual posting. In the meantime, a copy is attached to this mail. As 
> you can see, I went ahead and made the change I proposed above: 
> citing X9.63 as the normative standard for the KDF in RFC 5753, wit 
> SEC1 as an informative reference.
>
> Thoughts?
>
> Cheers.
>
> --
> 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
>