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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 21 February 2019 14:05 UTC

Return-Path: <alexey.melnikov@isode.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 93CF3129284 for <crypto-panel@ietfa.amsl.com>; Thu, 21 Feb 2019 06:05:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 Q66R4sObo_uA for <crypto-panel@ietfa.amsl.com>; Thu, 21 Feb 2019 06:05:32 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A5E3B1279E6 for <crypto-panel@irtf.org>; Thu, 21 Feb 2019 06:05:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1550757927; d=isode.com; s=june2016; i=@isode.com; bh=v026KldSIn5JMDBQ8fgdk9QpYhK/BjdF8NIuN45vRgc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FR7B5j0NCM6YEOPz0A9CGvryTpacUyig2XMabH8/RuKlrZ1FKn+2i1OFkw0YoQ0vFEqO4g ImfkMsbfBzUUD9XDlp1JW7cAplT27IDFWxzVNBovfFwnUhHrAQxmYEQNdnalq1mXhOmuOu iNg66d/VOaMqGz2VTaDUmO9WqoBf7xY=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <XG6wJgBUXsV-@statler.isode.com>; Thu, 21 Feb 2019 14:05:27 +0000
To: "crypto-panel@irtf.org" <crypto-panel@irtf.org>
Cc: "'Roman D. Danyliw'" <rdd@cert.org>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <5e587cf8-2275-b682-e390-e83529a8d0d8@isode.com>
Date: Thu, 21 Feb 2019 14:05:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------878EE3B79122B8A274896112"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/Oiv3FJfigJ_-4HLd-69Nr-ylvUM>
Subject: [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:05:37 -0000

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) 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
[2] https://github.com/theisgroenbech/edhoc-proverif

Thank you,
Alexey