IETF Logo Mail Archive

Re: [Secdispatch] a proposed path forward on EDHOC/lightweight AKEs

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 03 June 2019 22:28 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC807120086 for <secdispatch@ietfa.amsl.com>; Mon, 3 Jun 2019 15:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BJg88y_Jinfo for <secdispatch@ietfa.amsl.com>; Mon, 3 Jun 2019 15:28:21 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7A2120033 for <secdispatch@ietf.org>; Mon, 3 Jun 2019 15:28:20 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A985380BE; Mon, 3 Jun 2019 18:27:07 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 8634B16A5; Mon, 3 Jun 2019 18:28:18 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 83D7DE69; Mon, 3 Jun 2019 18:28:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: secdispatch@ietf.org
In-Reply-To: <20190603204618.GD1902@prolepsis.kaduk.org>
References: <20190603204618.GD1902@prolepsis.kaduk.org>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 03 Jun 2019 18:28:18 -0400
Message-ID: <12299.1559600898@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/EC30WlIUXhdpwnmJbQuC2jMJmGs>
Subject: Re: [Secdispatch] a proposed path forward on EDHOC/lightweight AKEs
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2019 22:28:23 -0000

Benjamin Kaduk <kaduk@mit.edu> wrote:
    > As a starting point, we would propose to charter a LAKE WG as follows:

The charter text seems fine.
Thank you for considering to go directly to WG.

    > ==[ CHARTER ]==
    > Problem

    > Constrained environments using OSCORE in network environments such as
    > NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key
    > exchange (LAKE) that enables forward security.  'Lightweight' refers to:

    > * resource consumption, measured by bytes on the wire, wall-clock time to
    > complete, or power consumption
    > * the amount of new code required on end systems which already have an
    > OSCORE stack

    > Goals

    > This working group is intended to be a narrowly focused activity
    > intended to produce only at most one LAKE and close.

    > The working group will collaborate and coordinate with other IETF WGs
    > such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the
    > requirements and solution.  The WG will also evaluate prior work from
    > the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe.

    > Program of Work

    > The deliverables of this WG are:

    > 1. Design requirements of the LAKE in constrained environments (this
    > draft will not be published as an RFC but will be used to driving WG
    > consensus on the deliverable (2)

    > 2. Standardize a lightweight authenticated key exchange (LAKE) for
    > suitable for use in a documented class of constrained environments
    > ==[ CHARTER ]==

    > We seek your feedback on this proposed approach.  Please share your
    > comments by Tuesday, June 18.  To keep momentum going on this topic we
    > plan to request a BoF slot at IETF 105, though the agenda for such a
    > slot will depend strongly on how the mailing list discussion proceeds.

As it is difficult to enter conflicts for BOFs, it would be great if the
session request for this BOF could be done soonest, and that it include at a
minimum the following conflicts:
   1st: CORE ANIMA ACE LPWAN CBOR
   2nd: 6TISCH TLS SECDISPATCH ACME

Maybe Carsten or Goran have some additions here.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email