Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17

Felix Günther <mail@felixguenther.info> Wed, 02 November 2022 09:33 UTC

Return-Path: <SRS0=0bE5=3C=felixguenther.info=mail@cdc02.comdc.de>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640EBC15256B for <lake@ietfa.amsl.com>; Wed, 2 Nov 2022 02:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.648
X-Spam-Level:
X-Spam-Status: No, score=-6.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfWJw3awJH72 for <lake@ietfa.amsl.com>; Wed, 2 Nov 2022 02:33:01 -0700 (PDT)
Received: from cdc02.comdc.de (cdc02.comdc.de [136.243.4.87]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86398C14CE20 for <lake@ietf.org>; Wed, 2 Nov 2022 02:33:00 -0700 (PDT)
Received: from cdc02.comdc.de (cdc02.comdc.de.local [127.0.0.1]) by cdc02.comdc.de (Postfix) with ESMTP id 2E3A54F200D7 for <lake@ietf.org>; Wed, 2 Nov 2022 10:32:57 +0100 (CET)
Received: from [10.6.32.129] (195-176-113-212.net4.ethz.ch [195.176.113.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mail@felixguenther.info) by cdc02.comdc.de (Postfix) with ESMTPSA id 075464F20063 for <lake@ietf.org>; Wed, 2 Nov 2022 10:32:56 +0100 (CET)
Message-ID: <a7f7ee9a-6cd4-600c-7480-fc88ac35ce4a@felixguenther.info>
Date: Wed, 02 Nov 2022 10:32:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-US
To: lake@ietf.org
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
From: Felix Günther <mail@felixguenther.info>
In-Reply-To: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/3tVDWBtI-NdciJtq7Re7y8KwYq8>
Subject: Re: [Lake] 🔔 WG Last Call for draft-ietf-lake-edhoc-17
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2022 09:35:33 -0000

Hi all,

While we do not have any explicit comments on the document, we thought 
it is maybe still worthwhile to share the following analysis confirmation.

We updated our computational analysis of the SIG-SIG mode, of which Marc 
presented an earlier version at IETF 114, to draft 17. We could confirm that
  * with some of the later cryptographic suggestions (PR #276, #318) 
included,
  * EDHOC SIG-SIG achieves key exchange security (key secrecy and 
explicit authentication) in a strong model capturing potentially 
colliding credential identifiers,
  * assuming, among others, an "exclusive ownership" property of the 
signature scheme (established for Ed25519, conjectured for the way ECDSA 
is used in EDHOC SIG-SIG).

Our updated analysis is not publicly available yet at this point. Let us 
know if a public reference would be helpful for the draft RFC; we can 
also share the document individually upon request.


The last point actually maybe does lead to a comment on the document: 
Given the various security analyses EDHOC has seen and their insights 
being discussed in Section 8, would it make sense to add informative 
references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)?

Kind regards,
Felix Günther (with Marc Ilunga)


On 2022-10-14 12:24 +0200, Mališa Vučinić <malisa.vucinic@inria.fr> wrote:
> Hi all,
> 
> As discussed during the interim on 5 October 2022, this email triggers 
> the working group last call for the version 17 of the EDHOC draft, the 
> main item on the agenda of the LAKE working group.
> 
> The draft can be found at: 
> https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/ 
> <https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/>
> 
> Please state your position and comments to the list by 4 November 2022 
> so we can discuss them during the IETF 115 meeting in London.
> 
> Thanks,
> Mališa, for the chairs
> 
>