IETF Logo Mail Archive

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

"Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu> Wed, 09 March 2011 18:33 UTC

Return-Path: <prvs=2049ffe0e7=jherzog@ll.mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F093A6A02; Wed, 9 Mar 2011 10:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.847
X-Spam-Level:
X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmBiCi4pVerC; Wed, 9 Mar 2011 10:33:30 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by core3.amsl.com (Postfix) with ESMTP id 3FC353A6933; Wed, 9 Mar 2011 10:33:30 -0800 (PST)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p29IYf4t026025; Wed, 9 Mar 2011 13:34:41 -0500
From: "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>
To: Brian Weis <bew@cisco.com>
Date: Wed, 09 Mar 2011 13:34:40 -0500
Thread-Topic: Secdir review of draft-herzog-static-ecdh-05
Thread-Index: AcveiKcEiqs+K4A7TLSMukbPot0zIw==
Message-ID: <FFD02A42-A10C-4AE7-A763-5C2D1E1DFADA@ll.mit.edu>
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> <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com>
In-Reply-To: <3E69AF7B-D325-4FC5-A003-FEBA1997D67E@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-137--734066668"; 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-09_07:2011-03-09, 2011-03-09, 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-1103090118
X-Mailman-Approved-At: Wed, 09 Mar 2011 11:46:48 -0800
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
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2011 18:33:31 -0000

On Mar 8, 2011, at 12:13 PM, Brian Weis wrote:

>>>> 
>>>>> 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?
> 
> Sure, that's fine.


I've thought a little more about this, and change my proposal to:

* Reference RFC 6090 for ECDH in general, but
* SEC1 for co-factor ECDH, the public-key validation primitives, and the key-derivation function (KDF).

Unfortunately, none of those algorithms in the second bullet are present in RFC 6090. (Though the security considerations of RFC 6090 discuss why one would want to validate public keys, it doesn't describe how to do so.)


Any objections?

Thanks.
-- 
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    
Lexington, MA 02420-9185

v2.23.0 | Report a Bug | By Email