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

[Brian Weis <[e-mail]>]

Hi Jonathan,

On Mar 6, 2011, at 1:43 PM, Herzog, Jonathan - 0668 - MITLL wrote:

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

That'll do the trick nicely, I think.
> 
> 
>> 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.

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

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.

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

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).

Hope that helps,
Brian

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