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

[Uri Blumenthal <[e-mail]>]

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" <[e-mail]>:
> 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:  [phone]
> Technical Staff							fax:    [phone]
> Cyber Systems and Technology Group		email:  [e-mail]
> MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
> 244 Wood Street
> Lexington, MA 02420-9185
>