[Lake] LAKE next steps

Benjamin Kaduk <kaduk@mit.edu> Tue, 20 August 2019 15:50 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EAF7D120985; Tue, 20 Aug 2019 08:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 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] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id w5S5a0Hketqn; Tue, 20 Aug 2019 08:50:12 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (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 793D3120986; Tue, 20 Aug 2019 08:50:12 -0700 (PDT)
Received: from kduck.mit.edu ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7KFo7OC006446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Aug 2019 11:50:10 -0400
Date: Tue, 20 Aug 2019 10:50:07 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: lake@ietf.org
Cc: secdispatch@ietf.org
Message-ID: <20190820155006.GE60855@kduck.mit.edu>
Reply-To: lake@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk>
Subject: [Lake] LAKE next steps
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: Tue, 20 Aug 2019 15:50:16 -0000

Thank you to everyone who attended the LAKE BoF session! It was a
productive meeting that highlighted the community’s needs for work in this
space.  A key insight that emerged during the session was that there is a
fairly clear split between the “AKE for OSCORE” case and “general purpose
lightweight AKE” in terms of the set of requirements.  We are happy to note
a strong level of interest in a TLS-based solution that removes unnecessary
protocol fields and encoding redundancy, which has significant potential
for use in protocols that do not require traditional TLS cross-version
compatibility, in constrained and full-featured environments alike.
Likewise, we saw that the additional community engagement of a BoF was able
to provide new insights into the use cases and requirements for a LAKE [0],
both in the OSCORE and the more general case -- this is a great indication
of the value provided by the broad and cross-area IETF review process.

Based on the input received and energy in the room, we feel that it’s
appropriate to charter a WG to finish coalescing the requirements for the
OSCORE use case and evaluate solutions.  From we’ve seen so far, EDHOC
seems like the leading contender, especially with respect to the “reuse of
COSE algorithms” proposed requirement, but we of course welcome further
data (such as on the relative code footprint of core cryptographic
primitives vs. protocol integration for COSE/cTLS/etc.).

We also feel that it’s appropriate to find a home for work on cTLS to come
to fruition.  As noted during the BoF, this presents a multifaceted
problem, with input needed from TLS experts as to which parts of the
protocol are legacy artifacts vs. cryptographically necessary, and also
with input needed from domain experts on constrained devices as to which
protocol features are necessary and where to fall on the spectrum of
tradeoffs between fully general/full-featured and a stripped-down,
bare-bones feature set.  On the balance, though, it seems that discussion
of a general-purpose-but-compact TLS would be most effectively done in the
TLS WG with additional input and collaboration as needed.  We plan to ask
the TLS WG if there is interest in rechartering to take on this
“constrained TLS” work item (and we note that this includes thinking about
whether it is best done as a standalone specification or a “patch” or
“filter” to stock TLS that could apply to multiple TLS versions).

For the sake of facilitating discussion, we include draft charter text for
the OSCORE case, modified based on input from the BoF from the version that
was previously sent to secdispatch@ietf:

==[ CHARTER ]==

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


This working group is intended to be a narrowly focused activity
intended to produce at most one LAKE for OSCORE usage 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 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 lightweight authenticated key exchange
protocol for OSCORE (this draft will not be published as an RFC but will be
used to drive WG consensus on the deliverable (2)

2. Specify a lightweight authenticated key exchange protocol suitable for
use in constrained environments using OSCORE
==[ CHARTER ]==


Ben and Roman

[0]  For example, the total number of key exchange operations expected to
be performed over the lifetime of the device, as might be compared against
the total lifetime energy budget; and a request to make explicit what had
previously been implicit assumptions about the cost of various operations
(on various axes).