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

Sean Turner <> Mon, 14 March 2011 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F27A43A67EE for <>; Mon, 14 Mar 2011 12:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Ovi4LknMC2Y for <>; Mon, 14 Mar 2011 12:50:55 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 897C33A6D9A for <>; Mon, 14 Mar 2011 12:50:50 -0700 (PDT)
Received: from [] by with NNFMP; 14 Mar 2011 19:52:11 -0000
Received: from [] by with NNFMP; 14 Mar 2011 19:52:11 -0000
Received: from [] by with NNFMP; 14 Mar 2011 19:52:11 -0000
Received: (qmail 25056 invoked from network); 14 Mar 2011 19:52:11 -0000
Received: from thunderfish.local (turners@ with plain) by with SMTP; 14 Mar 2011 12:52:11 -0700 PDT
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: 3Qaz2pUVM1kWc_2FnN.qGDS31diy14Zi1VEKjxuYxMuojYG Fc0jreKtzAS1IjwrTbE78ZJKmegbH3xBEK3WnAX51kPU3avu4YFgXuYYShIV sB0OZIIA0dRt6PKdaKN9uaV56ZzXsZAMtIVp.zta4eSm506hiBxP5rPKFj9C hBG8UJK_R5om4kyzvekFwIc6f7J0gDbOnVJZVpNhrCYHgHpP506yaOqVNMUc RJ.j5TcqVc5IYtUovjtKRmAfm6HuKfL2WQlEyxtxaPEEKIG1UXGttA08-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Mon, 14 Mar 2011 15:52:10 -0400
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: "Herzog, Jonathan - 0668 - MITLL" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05
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: Mon, 14 Mar 2011 19:50:56 -0000

On 3/14/11 9:47 AM, Herzog, Jonathan - 0668 - MITLL wrote:
> 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?

While I'd prefer a pointer to NIST specs, I think we have to maintain 
compatibility with RFC 5753 (i.e., doing the KDF one way for SS ECDH and 
another way for ES ECDH just seems like a bad idea).  I like the 
approach of pointing to ANSI normatively and SEC1 informatively.