Re: [Lake] đź”” WG Last Call for draft-ietf-lake-edhoc-17

Mališa Vučinić <malisa.vucinic@inria.fr> Sat, 05 November 2022 11:41 UTC

Return-Path: <malisa.vucinic@inria.fr>
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 2D968C1522C5 for <lake@ietfa.amsl.com>; Sat, 5 Nov 2022 04:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr
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 KkuhXxMJjgGt for <lake@ietfa.amsl.com>; Sat, 5 Nov 2022 04:41:18 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E33AC1522C6 for <lake@ietf.org>; Sat, 5 Nov 2022 04:41:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=from:content-transfer-encoding:mime-version:subject:date: references:to:in-reply-to:message-id; bh=A2w/UlZv4FpdUdLFLjqoYS9WTOjen40iDyV0ZJnZNvA=; b=DlQWTYy+LOSilH1ykc0DSBmd8QxacCudf1OGkiJs4X/StnvrBq6eorwW 3PJ95cAz73njCqSwMdtob7OcfafQ+5rZLQOA7h49XTRw2i1LbQlubL9RU ZjnfELo2A6Xjf9jaPUyIZCEz7c7Ky5i8Q7cBu5bxCMMJU2LABe3o7+cIN Q=;
Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=malisa.vucinic@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos;i="5.96,140,1665439200"; d="scan'208";a="75174266"
Received: from dhcp-8270.meeting.ietf.org (HELO smtpclient.apple) ([31.133.130.112]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Nov 2022 12:41:14 +0100
From: Mališa Vučinić <malisa.vucinic@inria.fr>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Sat, 05 Nov 2022 11:41:12 +0000
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
To: lake@ietf.org
In-Reply-To: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr>
Message-Id: <72C896F4-5725-4553-AC99-76F024DC154E@inria.fr>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/cDbLGYIGEZ6Z36VoaHwR6HDIRKs>
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: Sat, 05 Nov 2022 11:41:23 -0000

Hi all,

I am sending below a couple of points and nits I found when reading the draft top to bottom. Generally, I find the draft in a good shape to proceed with publication. 

One point I would like to discuss is whether it would be useful to specify a protocol state machine in this draft. Different steps related to message and error processing are scattered throughout the Section 5, but it would be very useful from the implementor’s point of view to have the valid states summarized and illustrated through a figure. I guess something similar to Appendix A of RFC 8446 would be nice.

Another point that introduced confusion for me when implementing this draft is whether the transcript hashes should be CBOR wrapped.  For example, in Section 5.3.2. TH_2 is first defined as the output of the hash function TH_2 = H( G_Y, C_R, H(message_1) ), only to be followed by the sentence saying "The transcript hash TH_2 is a CBOR encoded bstr”. I find confusing here whether the definition of TH_2 includes the CBOR byte string wrapping or not, which is important for further uses of transcript hashes in the derivation of the keying material. Same applies for TH_3 and TH_4. It is worthwhile to note here that we interop’d using raw values of transcript hashes without CBOR byte string wrapping. If this is the way the transcript hashes were intended to be defined, then I do not understand the purpose of the quoted sentence.

I also noted a couple of remnants that seem to be already signaled in github, remnant in issue #346 on transcript hash, and the inconsistent use of session key terminology (PRK_out vs session key) signaled by Charlie Jacomme. 

Minor nits to be fixed (possibly already signaled by others):

“Section 1.1: EDHOC is designed for highly constrained settings making it especially suitable for low-power wide area networks [RFC8376] such as Cellular IoT, 6TiSCH, and LoRaWAN. “
Note that 6TiSCH is not a wide area network. Removing “wide area” from the quoted sentence, i.e. saying “low-power networks” would work.

- Section 3.3.1: s/communications/communication
- Section 3.7: s/COSE always use/COSE always uses
- Section 3.8: s/need to register/needs to register
- Section 6: s/Errors messages in EDHOC/Error messages in EDHOC
- Section 8.2: s/EHDOC/EDHOC

That would be it, congrats to the author team for getting the specification to this shape. Finally, apologies for sending this review a morning after the deadline!

Mališa

> On Oct 14, 2022, at 11:24, 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/
> 
> 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
> 
> -- 
> Lake mailing list
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake