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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 09 March 2011 20:30 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 C740F3A6AA8; Wed, 9 Mar 2011 12:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.467
X-Spam-Level:
X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100]
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 J6WDkKbNcdgC; Wed, 9 Mar 2011 12:30:31 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id DDB6C3A6969; Wed, 9 Mar 2011 12:30:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0AE453E4087; Wed, 9 Mar 2011 20:31:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299702704; bh=XU9+hL2VuU6kjP ogG1U1BcGqKTyYRSbOhoeHfgmNvrA=; b=k5uaBkyeE4npTI1mt2/VI3T4/xf6Un Xjg1RV3P1I/K4hQnbAUecbgy6wfn2rTmWLUTz95Znk0qzS/cEUzqbUxIpORI8jt5 pRyQCIRFVtCnpYdiKMm7W4mqYELxvoJ4yGI408Rv6Z56LNKD76tdKv7iukoIG1A1 1e8B0O+rNd8LfFAFul/4pmfYSWqH4a40MbK74X+R55ZmczdkX68+PfNkz45MBK29 2vRcogEvgu7J7XBaGXeBtoIHWncXf95Qg/AjYZufRBj7RHBHkZZT/G/76bDc11vU 4NGYC8xKv8xPyV4kxUakrr7t2LucIQDGDiESUwf2w8g1ppKfffoUXfrw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id b0kUZCCwt71F; Wed, 9 Mar 2011 20:31:44 +0000 (GMT)
Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 62A9A3E4084; Wed, 9 Mar 2011 20:31:42 +0000 (GMT)
Message-ID: <4D77E3AE.5060903@cs.tcd.ie>
Date: Wed, 09 Mar 2011 20:31:42 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: "Herzog, Jonathan - 0668 - MITLL" <jherzog@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> <FFD02A42-A10C-4AE7-A763-5C2D1E1DFADA@ll.mit.edu> <BA430CB6-FA7D-4A56-82CF-B72F0857C586@cisco.com>
In-Reply-To: <BA430CB6-FA7D-4A56-82CF-B72F0857C586@cisco.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-herzog-static-ecdh@tools.ietf.org" <draft-herzog-static-ecdh@tools.ietf.org>, "iesg@ietf.org" <iesg@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 20:30:33 -0000

Hi,

I've three concerns about this.

1) Now that we have 6090, if there's a way to do any ECC stuff
that can be built *only* on that, then that IMO gives a much
better basis on which implementers might have confidence in
their IPR situation. I think every reference to e.g. [SEC1]
included muddies those waters somewhat and hence may further
delay widespread adoption of ECC. Since the authors presumably
would like to see adoption, I wonder is there any way to
excise [SEC1] entirely and just use 6090 or other things with
perhaps clearer IPR? (If there are technical issues with how
to only use 6090 perhaps checking with cfrg and/or the authors
of 6090 would help.)

2) If [SEC1] remains as a reference, do we expect to get an
IPR declaration related to this? Have the authors asked anyone
from Certicom?

3) As far as I recall the only use-case specific to static-static
is that it allows employers to wiretap much more easily that
ephemeral-static. Am I right there? (Its been a while.) If not,
then I would suggest adding some use-case so that people might
know when to go for this setup and when to go for
ephemeral-static. If I am right above, then I think that warrants
some security consideration and even more guidance as to when
its appropriate to use static-static. (And I'd have to wonder
if its worthwhile as an RFC personally, but then I guess some
"customers" do like static-static for exactly this reason.)

Thanks,
Stephen.

On 09/03/11 18:53, Brian Weis wrote:
> Hi Jonathan,
> 
> No objections.
> 
> Thanks,
> Brian
> 
> On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote:
> 
>>
>> 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
>>
> 
>