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

[Brian Weis <[e-mail]>]

Hi Jonathan,

On Mar 8, 2011, at 8:10 AM, Herzog, Jonathan - 0668 - MITLL wrote:

> 
> On Mar 8, 2011, at 12:15 AM, Brian Weis wrote:
> 
>> Hi Jonathan,
>> 
>> On Mar 6, 2011, at 1:43 PM, Herzog, Jonathan - 0668 - MITLL wrote:
>>> 
>>> I plan to address these comments and submit a new draft in the next few days. Before I do, however, do you mind if I asked you a few questions?
> 
> 
> [snip]
> 
> 
>>> 
>>> And the rest of the introduction remains the same. Do you think this will be enough to orient the reader correctly?
>> 
>> That'll do the trick nicely, I think.
> 
> Excellent. Thanks.
> 
> 
> 
>>> 
>>>> 2. Reference [SEC1] is heavily referenced in this document, for both a definition of ECDH and specific methods for using ECDH. But it would be good to also mention RFC 6090, which is the best IETF document describing ECDH.
>>> 
>>> I was not previous aware of this RFC-- my bad. I have added it as an informative reference, but continued to refer to [Sec1] as the normative reference for the ECDH operation. Or do you think that RFC 6090 should be the normative reference?
>> 
>> I would suggesting using RFC 6090 for a normative reference to ECDH if you need such a reference. But I don't believe RFC 6090 discusses static-static consideration or issues at all, so for that [Sec1] seems to be the appropriate normative reference.
> 
> I'm a little uneasy with using RFC 6090 as a normative reference for ECDH, as my impression is that the rest of CMS uses SEC1 as the normative reference. (See RFC 5753.) This may be because RFC 6090 is so new, but I'm worried that switching to RFC 6090 as the normative reference for ECDH will introduce subtle incompatibilities.
> 
> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I think), or the use of the SharedInfo/ukm value.
> 
> Given this, do you mind if I keep SEC1 as normative and use RFC 6090 as informative?

Sure, that's fine.

[snip]

> 
>>> Do I need to explicitly require that the SharedInfo value be used?
>> 
>> I think your requirements are fine. But because you discuss both ukm and SharedInfo, I would clarifying their linkage. For example, in your Security Considerations you could mention the role of SharedInfo to permute the session so that two sessions setup between the same entities will be keyed independently, point out that CMS specifies that ukm is to be the value used in SharedInfo, and how ukm is determined so that it will properly do its job. This is also rationale for the SHOULD in section 2.1.
> 
> Good point. What do you think of the following change?

Bingo! That explanation seems both complete and clear to me. With that inclusion, I think its ready to publish.

Thanks,
Brian

> 
> WAS
> 
> 
>   Extreme care must be used when using static-static Diffie-Hellman
>   (either standard or cofactor) without the use of some per-message
>   value in ukm.  If no message-specific information is used (such as a
>   counter value, or a fresh random string) then the resulting secret
>   key could be used in more than one message.  Under some
>   circumstances, this will open the sender to the 'small subgroup'
>   attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re-
>   used Diffie-Hellman keys.  Applications that cannot tolerate the
>   inclusion of per-message information in ukm (due to bandwidth
>   requirements, for example) SHOULD NOT use static-static ECDH for a
>   recipient without ascertaining that the recipient knows the private
>   value associated with their certified Diffie-Hellman value. 
> 
> IS NOW
> 
> 
>   Extreme care must be used when using static-static Diffie-Hellman
>   (either standard or cofactor) without the use of some per-message
>   value in ukm.  As described in [RFC5753], the ukm value (if present)
>   will be embedded in a ECC-CMS-SharedInfo structure and the DER-
>   encoding of this structure will be used as the 'SharedInfo' input to
>   the ECDH key-agreement operation in [SEC1], Section 6.1.3.  The
>   purpose of this input is to add a message-unique value to the key-
>   distribution function so that two different sessions of static-static
>   ECDH between a given pair of agents result in independent keys.  If
>   the ukm value is not used or is re-used, on the other hand, then the
>   ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely not
>   vary from message to message.  In this case, the two agents will re-
>   use the same keying material across multiple messages.  This is
>   considered to be bad cryptographic practice and may open the sender
>   to attacks on Diffie-Hellman (e.g., the 'small subgroup' attack
>   [MenezesUstaoglu] or other, yet-undiscovered attacks).
> 
>   It is for these reasons that Section 2.1 states that message-senders
>   SHOULD include the ukm and SHOULD ensure that the value of ukm is
>   unique to the message being sent.  One way to ensure the uniqueness
>   of ukm is for the message sender to choose a 'sufficiently long'
>   random string for each message (where, as a rule of thumb, a
>   'sufficiently long' string is one at least as long as the keys used
>   by the key-wrap algorithm identified in the keyEncryptionAlgorithm
>   field of the KeyAgreeRecipientInfo structure).  However, other
>   methods (such as a counter) are possible.  Also, applications which
>   cannot tolerate the inclusion of per-message information in ukm (due
>   to bandwidth requirements, for example) SHOULD NOT use static-static
>   ECDH for a recipient without ascertaining that the recipient knows
>   the private value associated with their certified Diffie-Hellman
>   value.
> 
> 
> 
>> BTW, the RFC Index search engine says that RFC 3278 has been obsoleted by RFC 5753. You should reference that one (which hopefully makes the same statements regarding ukm).
> 
> Whoops! Good catch. Fortunately, the draft already did reference RFC 5753. My brain, on the other hand, seem to be taking longer to catch up. ;-)
> 
> 
> 
> Thanks.
> 
> -- 
> 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
> 


-- 
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]