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

[Sean Turner <[e-mail]>]

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.

spt