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

David McGrew <mcgrew@cisco.com> Wed, 09 March 2011 20:55 UTC

Return-Path: <mcgrew@cisco.com>
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 5F8AF3A6ABC; Wed, 9 Mar 2011 12:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.036
X-Spam-Level:
X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 WAdsGjTu+U1X; Wed, 9 Mar 2011 12:55:28 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C4A9D3A6943; Wed, 9 Mar 2011 12:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=4808; q=dns/txt; s=iport; t=1299704205; x=1300913805; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=4a7A70vYN9HFzNSqQeWtSDyPEyQPjWIO07Ez5YkfLrw=; b=dtOTLSQBAR2DE9g6pzrTclY6WXZgS7u+ySGlyb9VeYRpZVXdGPRNFuCm +zAlXIHGPQsYoDS1aQJ1cqTGuVoO5yWSZeeu7q/ZMtQQOoE1kz64wWbAo qswNsL7oQpZHcyHSSiof16QXY748gOeBThRzcHbY9AKTNXobF/7MvLj7o Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKZ4d02rR7H+/2dsb2JhbACmcXSnR5xPgxiCTQSFIocY
X-IronPort-AV: E=Sophos;i="4.62,292,1297036800"; d="scan'208";a="275938354"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2011 20:56:45 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p29Kuiai003357; Wed, 9 Mar 2011 20:56:44 GMT
Message-Id: <88DD8520-CE2A-41BF-B13F-74D3B51A73A5@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <4D77E3AE.5060903@cs.tcd.ie>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 9 Mar 2011 12:56:43 -0800
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> <4D77E3AE.5060903@cs.tcd.ie>
X-Mailer: Apple Mail (2.936)
Cc: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-herzog-static-ecdh@tools.ietf.org" <draft-herzog-static-ecdh@tools.ietf.org>, "Herzog, Jonathan - 0668 - MITLL" <jherzog@ll.mit.edu>
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:55:31 -0000

Hi Stephen,

On Mar 9, 2011, at 12:31 PM, Stephen Farrell wrote:

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

I think that RFC6090, combined with NIST SP800-56A, could be used as  
the sole normative reference for static-static ECDH (the vanilla  
flavored variant, not the cofactor variant).  I sketched some thoughts  
in that direction in a separate email.  Jonathan, what do you think?

Jonathan was correct that RFC6090 can't be used as a reference for the  
cofactor variant.

David


> 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
>>>
>>
>>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir