Re: [Secdispatch] [Lake] LAKE next steps

Rene Struik <rstruik.ext@gmail.com> Tue, 20 August 2019 16:13 UTC

Return-Path: <rstruik.ext@gmail.com>
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 CD27D1200EB; Tue, 20 Aug 2019 09:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8HekehnDU98Z; Tue, 20 Aug 2019 09:13:22 -0700 (PDT)
Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5DAC12095B; Tue, 20 Aug 2019 09:13:21 -0700 (PDT)
Received: by mail-io1-xd43.google.com with SMTP id t6so13349951ios.7; Tue, 20 Aug 2019 09:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=aPge+sF9H+Hd3mvf6hZb+KecI9yb8qJSxSMM5xnT+Qo=; b=aQPHY0vyz8Rrzceivc4blnucTpTuSg7SPA6tUbAU3wpuVX2Ea5HghXkk93gi4dSEMg gejCAIHAvmiwpoSvsxJ3y9hKKm0/vbQJgQr2IFQ7MLk0eWI6ClSmNWzmrGuTzTNCmGXq cvRtyRoRUGzt3mcNVFzSnxjELXG4i33lEQSFS2Nqz847fALaDinfF2DcpGqEzQ3EpboR 6osJzET+NTbB0/9+StKLTWrUxWY1M26sd5ahWPI54KzJWk8ux8Y/wecEZmy3dc5CKi6k mFrzGjhSmC9+E5W0WbmcfwDLQikLghC6nE8K7H/que6bNNFYq9vjxmi/a6yub94GVfIP 2RQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aPge+sF9H+Hd3mvf6hZb+KecI9yb8qJSxSMM5xnT+Qo=; b=Ny70cOwYqCtx3KzpnM84rpU4ecut2c7cle54c5XC0KPa04moNF3TIXEethzBJ3WTCz VmtjrB3M15gI2k6Z4gqyn5oZuA4e1hrctEJvAltxb5vbvnlo1AnJ7mpjdXA2yk/Fk/2m avoP/38E97mu803lrEkk/ax/H2B2bo0xOljIYR/V5MA7sPb5f6je7BS6bWaz6n/nibW4 oBgWIj6ZmM11JVgHLAOPIzxD++dss8fUa2lTSNZLo5hipEubif+tiXgudAtTh04piFen yVqTk7Gp5kB9Pf8W66E1VLtjBMvpkfpRIPV9EFn4MByh5cPycIH/Bec1NxE0DlRFtxyK R5/A==
X-Gm-Message-State: APjAAAUoquk8c0qLfoVsXTN6WLbPQ3R4lSRtSTsK3Vybr3yj9NAuFyM/ 2ifobuUasRco/paNGyxJ50d9l5bc
X-Google-Smtp-Source: APXvYqyJb3O7xb95XViI2CyM3srR9wxX9KpPQq1GYb/AfqYZP4yjB4xiaixRYP4yToGpOGV2b1o9vg==
X-Received: by 2002:a6b:917:: with SMTP id t23mr25782809ioi.174.1566317600982; Tue, 20 Aug 2019 09:13:20 -0700 (PDT)
Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id q12sm17173351ioh.8.2019.08.20.09.13.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Aug 2019 09:13:20 -0700 (PDT)
To: lake@ietf.org, Benjamin Kaduk <kaduk@mit.edu>
Cc: secdispatch@ietf.org
References: <20190820155006.GE60855@kduck.mit.edu>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com>
Date: Tue, 20 Aug 2019 12:13:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190820155006.GE60855@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/jVS2CVQRgt5xb0iuYmLU5wyNozo>
Subject: Re: [Secdispatch] [Lake] LAKE next steps
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: Tue, 20 Aug 2019 16:13:24 -0000

Hi Ben:

 From the discussion at the LAKE BoF, it seemed there was strong support 
[1] for also tackling the broader scenario (triggered by David Thaler's 
suggested dichotomy at the microphone).

I have some trouble seeing suggested next steps on tackling this broader 
problem in you email below. If you could elaborate on how you see this 
broader topic ("general purpose lightweight AKE") find a home in terms 
of next steps, that would be great. (In my mind, this is not simply "TLS 
with compressed representation".)

Best regards, Rene

[1] (excerpted from draft LAKES BOF minutes ([minutes-105-lake-00]):
Is OSCORE Key exchange a ('the narrow') problem that needs being solved?
strong on yes, none on negative question
Is broader constrained scenario a problem that needs solving?
strong on yes, low on no

On 8/20/2019 11:50 AM, Benjamin Kaduk wrote:
> 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 ]==
> 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 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 ]==
>
> Thanks,
>
> 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).
>

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363