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

"Herzog, Jonathan - 0668 - MITLL" <> Sun, 06 March 2011 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F7913A688B; Sun, 6 Mar 2011 13:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.847
X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jmzeYBxCkMmz; Sun, 6 Mar 2011 13:42:12 -0800 (PST)
Received: from (MX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 7A9C13A6845; Sun, 6 Mar 2011 13:42:11 -0800 (PST)
Received: from ( by (unknown) with ESMTP id p26LhKu0031978; Sun, 6 Mar 2011 16:43:20 -0500
From: "Herzog, Jonathan - 0668 - MITLL" <>
To: Brian Weis <>
Date: Sun, 06 Mar 2011 16:42:47 -0500
Thread-Topic: Secdir review of draft-herzog-static-ecdh-05
Thread-Index: AcvcR4KihL0SzAu+RdmncC3oRytiVg==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-112--981979745"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-03-06_04:2011-03-04, 2011-03-06, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=8 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1103060102
X-Mailman-Approved-At: Tue, 08 Mar 2011 08:18:12 -0800
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Mar 2011 21:42:13 -0000

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


Jonathan Herzog							voice:  (781) 981-2356
Technical Staff							fax:    (781) 981-7687
Cyber Systems and Technology Group		email:
MIT Lincoln Laboratory               			www:
244 Wood Street    
Lexington, MA 02420-9185