Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Brian Weis <bew@cisco.com>
In-Reply-To: <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu>
Date: Tue, 8 Mar 2011 09:13:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com>
References: <D858A225-D1D1-497D-BA40-A66D3F55AD57@cisco.com>
 <552BBAA9-712F-49B4-8A5F-C671C3817C05@ll.mit.edu>
 <AA323705-436C-4B71-8B51-D2CA9E4E140C@cisco.com>
 <47CF9528-81A1-49D7-8D4B-B1DCC136581E@ll.mit.edu>
To: "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>
Cc: "draft-herzog-static-ecdh@tools.ietf.org"
 <draft-herzog-static-ecdh@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>,
 "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05
Precedence: list

Hi Jonathan,

On Mar 8, 2011, at 8:10 AM, Herzog, Jonathan - 0668 - MITLL wrote:

>=20
> On Mar 8, 2011, at 12:15 AM, Brian Weis wrote:
>=20
>> Hi Jonathan,
>>=20
>> On Mar 6, 2011, at 1:43 PM, Herzog, Jonathan - 0668 - MITLL wrote:
>>>=20
>>> 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?
>=20
>=20
> [snip]
>=20
>=20
>>>=20
>>> And the rest of the introduction remains the same. Do you think this =
will be enough to orient the reader correctly?
>>=20
>> That'll do the trick nicely, I think.
>=20
> Excellent. Thanks.
>=20
>=20
>=20
>>>=20
>>>> 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.
>>>=20
>>> 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?
>>=20
>> 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.
>=20
> 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.
>=20
> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I =
think), or the use of the SharedInfo/ukm value.
>=20
> Given this, do you mind if I keep SEC1 as normative and use RFC 6090 =
as informative?

Sure, that's fine.

[snip]

>=20
>>> Do I need to explicitly require that the SharedInfo value be used?
>>=20
>> 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.
>=20
> 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

>=20
> WAS
>=20
>=20
>   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.=20
>=20
> IS NOW
>=20
>=20
>   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).
>=20
>   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.
>=20
>=20
>=20
>> 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).
>=20
> 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. =
;-)
>=20
>=20
>=20
> Thanks.
>=20
> --=20
> Jonathan Herzog							=
voice:  (781) 981-2356
> Technical Staff							=
fax:    (781) 981-7687
> Cyber Systems and Technology Group		email:  =
jherzog@ll.mit.edu
> MIT Lincoln Laboratory               			www:    =
http://www.ll.mit.edu/CST/
> 244 Wood Street   =20
> Lexington, MA 02420-9185
>=20


--=20
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com