Re: [Crypto-panel] Request to review: draft-selander-ace-cose-ecdhe-11

Russ Housley <housley@vigilsec.com> Thu, 21 February 2019 14:54 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F131286E7 for <crypto-panel@ietfa.amsl.com>; Thu, 21 Feb 2019 06:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AKodenSXahe for <crypto-panel@ietfa.amsl.com>; Thu, 21 Feb 2019 06:53:57 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E778B12D7F8 for <crypto-panel@irtf.org>; Thu, 21 Feb 2019 06:53:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A7F25300AA4 for <crypto-panel@irtf.org>; Thu, 21 Feb 2019 09:35:38 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m-4SrzBydCAJ for <crypto-panel@irtf.org>; Thu, 21 Feb 2019 09:35:36 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 51E4530024F; Thu, 21 Feb 2019 09:35:36 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <391B20B9-283A-4B36-805A-251D190B2E30@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0C9F4CA3-7F43-4F75-B29B-380F1B7DAE3F"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 21 Feb 2019 09:53:52 -0500
In-Reply-To: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com>
Cc: "crypto-panel@irtf.org" <crypto-panel@irtf.org>, "Roman D. Danyliw" <rdd@cert.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/prLh-50o5ZwqtfEDPILhjdiWzdQ>
Subject: Re: [Crypto-panel] Request to review: draft-selander-ace-cose-ecdhe-11
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 14:54:00 -0000

Yes, I can take a look at it next week.

Russ


> On Feb 21, 2019, at 9:05 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
> Dear Crypto Panel members,
> 
> CFRG chairs received a request to review this document (maybe even 2 reviews), ideally by March 4. (If you miss the deadline, a review that is completed later is still useful.) Any takers?
> 
> In particular, the review should concentrate on the following aspects of the proposal:
> 
> EDHOC (https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe-11 <https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe-11>) is being proposed as a new AKE to meet the need of constrained/IoT environments (such as those considered by the ACE WG). Formal analysis on -08 was conducted by [1] [2]. A review by the Crypto Review Panel would be helpful to evaluate the security properties (mutual authentication, PFS, and identity protection) claimed by the draft:
> 
> ** Top-line: does EDHOC provide the security properties it asserts?  How do we reason about/approach answering  that question?
> ** Is this draft complete -- what would you like to see that isn't written?
> ** What areas of the draft or features of the protocol require further analysis or polish?  Are the prerequisite/assumptions clear enough?
> ** Are the choice of ciphersuites acceptable? 
> ** Does the formal analysis in [1] appear credible?
> ** Does -11 appear to have addressed the concerned outlined by [1] in -08? (The authors of [1] are working on an update of the analysis on -11)
> 
> A related key question being discussed is "ignoring whether the security properties of EDHOC are valid, can the 'lightweight property of EDHOC' be realized with another protocol"
> 
> [1] https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf <https://link.springer.com/content/pdf/10.1007%2F978-3-030-04762-7_2.pdf>
> [2] https://github.com/theisgroenbech/edhoc-proverif <https://github.com/theisgroenbech/edhoc-proverif>
> 
> Thank you,
> Alexey
> _______________________________________________
> Crypto-panel mailing list
> Crypto-panel@irtf.org
> https://www.irtf.org/mailman/listinfo/crypto-panel