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

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

On Mar 3, 2011, at 1:39 AM, Brian Weis wrote:

> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 

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?

> 1. The Abstract and Introduction use the term "static-static" Elliptic Curve Diffie-Hellman key-agreement, which is a term not in common use. I guessed correctly that it meant the case where both participants in the key agreement were using static DH values, but I think until the term is define (later on in the Introduction) it would be clearer to say something like "Elliptic Curve Diffie-Hellman key-agreement where both participants use static Diffie-Hellman values".

Good catch. I have included your suggestion in both the abstract:

      "This document describes how to use 'static-static' Elliptic
      Curve Diffie-Hellman key-agreement (i.e., Elliptic Curve
      Diffie-Hellman where both participants use static Diffie-Hellman
      values) with the Cryptographic Message Syntax."

and the introduction:

   "This document describes how to use the static-static Elliptic-Curve
   Diffie-Hellman key agreement scheme (i.e., Elliptic Curve Diffie-
   Hellman [SEC1] where both participants use static Diffie-Hellman
   values) in the Cryptographic Message Syntax (CMS) [CMS]."

And the rest of the introduction remains the same. Do you think this will be enough to orient the reader correctly?


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



> 3. Generally, when two parties use static DH values over different exchanges they will use the same key for each exchange, which is generally not a good practice. I believe this is true for ECDH as well. Sections 2.2 and 2.3 mention "SharedInfo", which when used appropriately will permute the shared key such that the sessions are not keyed identically. But I believe the use of "SharedInfo" is optional, so I was expecting the Security Considerations to describe this scenario and at least say that "SharedInfo" SHOULD be used (or possibly MUST be used). It would be good to add this discussion to Security Considerations.

I'm not sure what you mean, here. Do you mean the SharedInfo value, or the ukm value? According to RFC 3278, the SharedInfo value is the DER encoding of the ECC-CMS-SharedInfo value:


      ECC-CMS-SharedInfo ::= SEQUENCE {
         keyInfo AlgorithmIdentifier,
         entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
         suppPubInfo [2] EXPLICIT OCTET STRING   }

Also according to that RFC:

      entityUInfo optionally contains additional keying material
      supplied by the sending agent.  When used with ECDH and CMS, the
      entityUInfo field contains the octet string ukm.

So, my read of the RFC is that ECDH in CMS will always use a SharedInfo value to derive keys, and this value will contain a per-message unique value if and only if the ukm field was used by the sender. Now, the ukm value *is* optional, according to RFC 5652, which is why our Draft says they SHOULD be used:

Section 2.1:

   o  ukm MAY be present or absent.  However, message originators SHOULD
      include the ukm.  As specified in [CMS], implementations MUST
      support ukm message recipient processing, so interoperability is
      not a concern if the ukm is present or absent.  The use of a fresh
      value for ukm will ensure that a different key is generated for
      each message between the same sender and receiver. ukm, if
      present, is placed in the entityUInfo field of the ECC-CMS-
      SharedInfo structure [CMS-ECC] and therefore used as an input to
      the key derivation function.


Security Considerations:

   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.

 
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? Do I need to explicitly require that the SharedInfo value be used?

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