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

"Herzog, Jonathan - 0668 - MITLL" <> Mon, 14 March 2011 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C55023A6D73; Mon, 14 Mar 2011 06:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.847
X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zjjjpW5QmyQX; Mon, 14 Mar 2011 06:45:57 -0700 (PDT)
Received: from (MX2.LL.MIT.EDU []) by (Postfix) with ESMTP id B948C3A6D72; Mon, 14 Mar 2011 06:45:56 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id p2EDlFfZ021630; Mon, 14 Mar 2011 09:47:15 -0400
From: "Herzog, Jonathan - 0668 - MITLL" <>
To: "Herzog, Jonathan - 0668 - MITLL" <>
Date: Mon, 14 Mar 2011 09:47:14 -0400
Thread-Topic: [secdir] Secdir review of draft-herzog-static-ecdh-05
Thread-Index: AcviTlPwVoTcbTm5SiGIfQxALeXKCw==
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-9--319312425"; 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-14_04:2011-03-14, 2011-03-14, 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-1103140068
X-Mailman-Approved-At: Tue, 15 Mar 2011 08:10:09 -0700
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 13:46:00 -0000

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.



Jonathan Herzog							voice:  (781) 981-2356
Technical Staff							fax:    (781) 981-7687
Cyber Systems and Technology Group		email:
MIT Lincoln Laboratory               			www:
244 Wood Street    
Lexington, MA 02420-9185