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

["Herzog, Jonathan - 0668 - MITLL" <[e-mail]>]

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?





[snip]

>> So I'm under the impression that our Draft requires a ukm value (with a SHOULD), and that RFC 3278 requires that this ukm value be included in a SharedInfor value which is used to derive keys. But did I misread RFC 3278?
> 
> I did notice the text regarding ukm in your I-D, but definitely missed linkage you quote from RFC 3278 above. So rather than misreading RFC 3278 you've clarified it for me. :-) Your explanation makes sense to me.

Ah, good.



>> 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?

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