Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Christopher Wood <caw@heapingbits.net> Sun, 21 June 2020 23:52 UTC

Return-Path: <caw@heapingbits.net>
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 2F6B13A0400 for <lake@ietfa.amsl.com>; Sun, 21 Jun 2020 16:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=Cqe/azYY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aB1/c8X+
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 Y7K8qnFvLwzQ for <lake@ietfa.amsl.com>; Sun, 21 Jun 2020 16:52:00 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3303A03F2 for <lake@ietf.org>; Sun, 21 Jun 2020 16:52:00 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id EEDC76D2 for <lake@ietf.org>; Sun, 21 Jun 2020 19:51:58 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Sun, 21 Jun 2020 19:51:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=qNmRc iFXBiNv53RvXA8MMJ9hUeoZonS8gyKg0lolS1c=; b=Cqe/azYYYEoEpYkcsdAJW q8wtXX1ZfyBQ7vGEKYGHTG+PVAG4XRozKyugr83vN0qNQpHYKAvUTRZCLWCXxb9l OXtBfN8mX9AyV3Vq+Ij2nZJHcOCAzz4xcMFakf82jC2zGqx5I7GNus+a/quRdOjd SqRswVS/wymVRbo3HHdPnF1RcHaoCtvFu8eutTNi49D3z84oih0HlXBnoGgBuxz3 RFN7I0NlhxZ8SoNJ1RI8JPZ0GxhjipKMFoIyLYZGSfOuf7aI/EMvLDcm9jqQHQhJ Bi7dr46FUEWqJaQrwwY3Bob1VXF9Nq/LfiYhvnRpWd9bAbA/e0Xuso9bLtOK5bA1 w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=qNmRciFXBiNv53RvXA8MMJ9hUeoZonS8gyKg0lolS 1c=; b=aB1/c8X+dVYs9d9ADn3Alf6aGHb+GJ8CWNAu7q1qeFjNUaG6hG0o8jfCf GBRVz+czI1NUZEjLah6tXkH2qZcNIMZhSbntJ1uD8DgHIjjI3ZRBjT6sbfy+DZAS 6/ocDg/zktny+sUfPJ1V1utHQj73fEceXfPGHab8ml6BjHWIVh1ePthpBoeL86tc m2CQasqswLzGRGRftqK2LxGYO4BHQ6PPz+Ww+pPnR2ffiFVCgabVgze+hyo0cndg eSeBPsxt2xdcOyddEU6+9q7mFr4XMe1IeyWaY0OX6xEEqRyPeb6XFkTRsatWS43q e+1HIpqhnv5l9wXRROTQhGLm29Eng==
X-ME-Sender: <xms:nvLvXqfTObpsVA277m7p-Qt-HPk32BFk3XcAA6Cpk843FHAk4PoG5A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekuddgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepteeivdelff eftddvlefhtdfhvdfgteffhedtjeelgfehkeelledvudffledtleeknecuffhomhgrihhn pehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:nvLvXkNEsXZk_70TkzAxJ3w9HtaQ9R9avBHGQenzzo4o-1E-mzjpXg> <xmx:nvLvXria8stCkBaSnSOQVKFVebPbE9bUhC2vMlRjCNol71VVM4KkKg> <xmx:nvLvXn-c0EMsexzpK77T7F8_3sJfu_Z7nRAM2OI-_Qx4e_XC_pJ1sw> <xmx:nvLvXjMw7uQ94DyeGL87TCe3Vf7iY0q8Dtupp_JSHCUToTKMJianQQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 426873C00A1; Sun, 21 Jun 2020 19:51:58 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345
Mime-Version: 1.0
Message-Id: <640332b4-188d-4ca7-9c41-310a3d0a73ed@www.fastmail.com>
In-Reply-To: <bfe96788-ec1a-2c9e-2fab-d52fb9fd8990@um.es>
References: <89EA6A63-AB99-4649-9F08-D6FBDE1DEF2F@inria.fr> <e86bb20d-8092-9b13-76b9-220de4f00e64@ri.se> <f8337bf9-40d2-557c-0e15-53571644900a@afnic.fr> <bfe96788-ec1a-2c9e-2fab-d52fb9fd8990@um.es>
Date: Sun, 21 Jun 2020 16:51:38 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: lake@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/oduO8DjyUl9pRQkfz4fDyGDOzNg>
Subject: Re: [Lake] =?utf-8?q?Call_for_adoption_for_draft-selander-lake-edhoc?= =?utf-8?q?_-_respond_by_June_22?=
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 21 Jun 2020 23:52:02 -0000

I do not support adoption.

The charter of this WG states:

   draft-selander-ace-cose-ecdhe is a candidate
   starting point for the LAKE produced by the WG. Any work available from
   TLS or other WGs that satisfies the determined requirements will also be
   evaluated for suitability, but does not preclude the WG from freely
   selecting its preferred LAKE for OSCORE.

Unless I missed it, work from TLS was not seriously evaluated for suitability.
In fact, it seems we jumped right over it and landed on draft-selander-ace-cose-ecdhe.
The cTLS authors demonstrated that this variant of the protocol can indeed meet
the requirements set out in draft-ietf-lake-reqs-04, without compromising any of
the benefits that the TLS ecosystem brings to the table. (Support for different
server authentication modes, for example, is something TLS is well equipped to support.)

I understand that the TLS WG adopted cTLS and will continue its development there.
However, that does not seem relevant for what this WG chooses. By analogy, this would
be similar to QUIC developing its own key exchange protocol since UDP is just slightly
different from TCP. Clearly, that was not the path chosen, and I think it would be a 
mistake to do that here without seriously considering cTLS. 

Best,
Chris

On Sun, Jun 21, 2020, at 1:13 PM, Jesus Sanchez-Gomez wrote:
> Hello All,
> 
> I support the adoption of this document.
> 
> I've worked with the technology in research projects/papers yielding 
> good results.
> 
> There are several use cases where this technology is a good solution for 
> different research projects at the University of Murcia and Odin Solutions.
> 
> While I've practical experience with this technology working 
> specifically in LoRaWAN, its design makes it a good fit for any 
> constrained radio link/LPWAN.
> 
> Also, it has potential to be implemented beyond LPWANs, like more 
> generic IoT scenarios with large scalability.
> 
> Best Regards,
> 
> 
> -- 
> Jesús Sánchez Gómez
> Contratado predoctoral // Phd Student. Fundación Séneca. Comunidad 
> Autónoma de la Región de Murcia
> +34 868 88 96 74
> +34 635 33 26 09
> jesus.sanchez4@um.es
> Department of Information and Communication Engineering
> Faculty of Computer Science
> University of Murcia
> 30100 Murcia, Spain
> 
> -- 
> Lake mailing list
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake
>