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

Christian Amsüss <christian@amsuess.com> Fri, 04 November 2022 23:54 UTC

Return-Path: <christian@amsuess.com>
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 9F4B0C1522C4 for <lake@ietfa.amsl.com>; Fri, 4 Nov 2022 16:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 iGd5vVnaYyLW for <lake@ietfa.amsl.com>; Fri, 4 Nov 2022 16:54:24 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8117DC1522C3 for <lake@ietf.org>; Fri, 4 Nov 2022 16:54:22 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 2A4NsF6i094151 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Nov 2022 00:54:15 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 536571387A; Sat, 5 Nov 2022 00:54:15 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::907]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 27A0D1736D; Sat, 5 Nov 2022 00:54:15 +0100 (CET)
Received: (nullmailer pid 5823 invoked by uid 1000); Fri, 04 Nov 2022 23:54:14 -0000
Date: Sat, 05 Nov 2022 00:54:14 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Mališa Vučinić <malisa.vucinic@inria.fr>, lake@ietf.org
Message-ID: <Y2WmJhJfREPrRC4y@hephaistos.amsuess.com>
References: <71E133FA-9C4D-4449-BC04-10F6D120D10D@inria.fr> <be4f7e47-4463-a464-9ed0-4f3c98f743de@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="/A2w3esWpeb2ZNTd"
Content-Disposition: inline
In-Reply-To: <be4f7e47-4463-a464-9ed0-4f3c98f743de@cs.tcd.ie>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/D-THUR-raS57JEfZjKFsMqFHl4M>
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: Fri, 04 Nov 2022 23:54:27 -0000

Hello Stephen,

On Sun, Oct 23, 2022 at 06:28:30PM +0100, Stephen Farrell wrote:
> If you've reviewed this version and find it ok, that's great
> but please do say so.
> 
> If you've not reviewed this version... please do:-)

I haven't had the time to do a full read and review of the latest
version, but I've checked my earlier comments, and they've been
addressed neatly (some with future work for this WG, CoRE or anyone
exercising its extension points, but for those comments that's a fine
resolution).

There is one minor piece of text I suggested at [141] that I think might
help EAD specifiers (who might not know that "we don't look into EDHOC
internals and key material, and the data we reveal is revealed by
design, so we're good" can be sufficient security analysis), but that's
merely a minor suggestion at this point.

Best regards
Christian

[141]: https://github.com/lake-wg/edhoc/issues/141#issuecomment-1081500628

-- 
Most people would leave. Not us. We're Vikings. We have stubbornness issues.
  -- Hiccup, son of Stoic