Re: [Lake] Lake charter call for comments
Rene Struik <rstruik.ext@gmail.com> Thu, 03 October 2019 15:14 UTC
Return-Path: <rstruik.ext@gmail.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 234B11209B0 for <lake@ietfa.amsl.com>; Thu, 3 Oct 2019 08:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 DDAWNtOHbmae for <lake@ietfa.amsl.com>; Thu, 3 Oct 2019 08:14:35 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 5D3871209A9 for <lake@ietf.org>; Thu, 3 Oct 2019 08:14:35 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id w12so6304590iol.11 for <lake@ietf.org>; Thu, 03 Oct 2019 08:14:35 -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-language; bh=4s7Ww9qd4A3fJBN3EvIhtuSWHAD9MGcSFN5r412huOw=; b=MSf9xFl4lkYXiBOqElcYT6UvZbDuTKuVNmeP8+/hKgDAyoEp4GLxDxBYO5V0+CnP52 OXqczvtO1ipl2zzUe21ujcyLc4NNMikzEtA26LDGTZUhOmkFIwydf0t293uthEDLeOLk CefUvst+AHY2s5EHm4eAadO1bBNEwNxiE1h2kCztJorMHh1rotuzOibIYwD7FzV0qmc7 2BQTcU/rDDQ/y0SdcsDi5Lh6fUDjsUt1oJYbHjTr1hGSiYQ4fRNLuQ8XgHdgEtk+VD+9 dZfMn1m267Ixz6K7/M27rvzSQX+2NCoQKAG/BHYkgcmIAaZTQ3UcARzkbdpHc20Hq5yC z9QQ==
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-language; bh=4s7Ww9qd4A3fJBN3EvIhtuSWHAD9MGcSFN5r412huOw=; b=fVF/jaDfbzqFvPowIrgv3EayrB4uGRlaB+7lS+7qxcfVukDRv/8vb2C5lVrLdgg1qX BiNhRkWKKGLmohr/u/UqTWIiBWvFbUP8NAmHbrS9YigN3yuNCdRlW2xHveMMsFwk38Od XiYToh+vCnzpPLqPTf4hBkEVPUPnh8yj9viovAA7IKRl6ovoCIeQNQBic0itfzB+hEyB XWy1SxOxbu6ZwddrEoV6jtUtJrQp20bkyC3+riZJHxcDNKlxSe+LOGTE8gm+vrwJcPoQ YJHzZerfCh4iqjwwddE09K5jp7uYEwg+b+pmBeZ2ftJzGX4A4iCBrkJBMNIduU7XsCwG O5bA==
X-Gm-Message-State: APjAAAUfpppuGTf1EL1RfJGN7x8TUs6owJ/GFF9+HurU2o9O5lavlCLk mgL6gzpq9hVnXX0f2nXCa4JyX40r
X-Google-Smtp-Source: APXvYqwSxIO/v3B3/jygkMV/UqmzPICXaqk2ydlmzD14vDTovJYaLWpJbWFZBON1BMj0uygVVeUjtw==
X-Received: by 2002:a92:58d7:: with SMTP id z84mr10452664ilf.101.1570115672524; Thu, 03 Oct 2019 08:14:32 -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 r22sm1733449ilb.85.2019.10.03.08.14.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Oct 2019 08:14:31 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: lake@ietf.org
References: <20190904045654.GY58050@kduck.mit.edu> <8a89b58b-d498-9cb5-90d3-9ae4dd0554b9@gmail.com> <20190925224857.GO6424@kduck.mit.edu>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <0f8e9d07-ffc0-7a0d-8aba-a3ea65937c1b@gmail.com>
Date: Thu, 03 Oct 2019 11:14:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20190925224857.GO6424@kduck.mit.edu>
Content-Type: multipart/alternative; boundary="------------66E5F3BDF4C72F1362094608"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/EOpWc97_wtku5mVTtztTsJlhCks>
Subject: Re: [Lake] Lake charter call for comments
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: Thu, 03 Oct 2019 15:14:42 -0000
Hi Ben: Thanks for your response. Some brief feedback below. I appreciate the analysis of how EDHOC (or cTLS) would fit into various radio schemes and protocol usages; that's perhaps more in-depth than we usually need to go at charter time but is definitely in scope for the kind of WG work I'm thinking of. RS>> My motivation for tackling the more general scenario (part #c of my comments on the draft charter) was based on closer scrutiny of how the outcome of the draft effort would fit-in with the target network environments mentioned in the draft charter (NB-IoT, 6TiSCH, and LoRaWAN). In other words: do we solve the right problem, vs. do we solve a stated problem right? From this scrutiny, it seems clear that the answer may be negative. As such, I do think this should be part of a sanity check for the charter. It is somewhat disappointing that, in the case of one of the two main triggers (6tisch), an answer to my question of more than half a year ago (March 5, 2019, 9.05am EST, seehttps://mailarchive.ietf.org/arch/msg/secdispatch/_mjOGfpgvKFu1HBagIZcrLLG_YU) is still missing and that evidence of careful thought in this area is, more than half a year later, still scant. This makes me wonder how one could defend keeping this application domain into the draft charter (presuming evidence-based decision processes). <<RS I especially appreciate the illustration of the inherent multi-party nature of the processes involved, and the sentiment that a consolidated approach to the problem could do better than the piecemeal approach. That said, I don't know that we have a clear enough understanding of the problem space and how to approach it that I could try to charter a WG to do the work; I think your suggestion of trying to have the IAB or T2TRG steer that discussion is reasonable, and I can try to see if the IAB is interested. I am curious, though, how many people on this list would be willing to put some time into such a discussion. RS>> I do think that people interested in real-life deployments have no choice but to consider the entire device and network lifecycle and have to consider the multi-party nature of protocol interactions to get a device up and running, change device ownership, etc. These topics seem to intersect quite well with topics areas in the t2trg charter, and seem to align with long-term issues with the IAB (https://tools.ietf.org/html/rfc2850#section-2.1); hence, me mentioning those as potential suitable platforms (whether one has to steer, I am not sure; providing a platform might be enough). It is hard to assess whether people on *this* [lake] list would be interested in this broader picture; however, I am not that concerned whether people who wish to see real-life deployment on massive scale happen will. <<RS Best regards, Rene On 9/25/2019 6:48 PM, Benjamin Kaduk wrote: > Hi Rene, > > Thanks for the thoughtful feedback. To cover the several fronts: > > It seems that you can accept the general tenor of the draft charter, but > want to revert the change made in response to (e.g.) > https://mailarchive.ietf.org/arch/msg/lake/OupmIV74eHqBcb-X0lsIB4q41pM . > While I agree that we should have an open view, I also know that the > trigger for having a LAKE BoF at all was a continued push to get some > disposition for EDHOC, and I think that many (if not most) people, myself > included, expect that EDHOC is the leading contender for adoption by a LAKE > WG. The proposed language about "starting point" is in pretty common usage > and is (I think) generally accepted in the IETF and IESG as indicating a > presumption that a draft is the likely candidate but leaving open the > possibility to adapt as circumstances change. I think that going back to a > "will consider [a list of things]" formulation does not really reflect the > expectations of most people, and prefer to use a formulation that gives as > accurate a picture as possible, while still leaving openness for change. > > You also ponder having a core key exchange framework without explicit > framing (so as to be adaptable to hardware, etc.); I think we've seen > roughly analogous situations with some algorithms that came out of the > CFRG: once in the IETF, we end up having to specify the details, and don't > always have great knowledge of the tradeoffs involved. There's been a > trend of asking the CFRG to be more concrete in their output and have fewer > options to choose from, which in my experience has worked more effectively > for the IETF. So, while having a somewhat malleable abstract model can > still be useful (and in many cases, a concrete protocol can be stripped > down to one), I lean towards having a concrete protocol with framing, that > is directly usable by IoT protocols with a minimum need for customization. > > You seem to be pushing back against making an assumption that [a compact > framing of] TLS is/should be the "general solution", and that's a fair > point. Do you also object to doing work on cTLS, or just to assuming that > it can meet the "general problem" discussed at the LAKE BoF? > > I appreciate the analysis of how EDHOC (or cTLS) would fit into various > radio schemes and protocol usages; that's perhaps more in-depth than we > usually need to go at charter time but is definitely in scope for the kind > of WG work I'm thinking of. I especially appreciate the illustration of > the inherent multi-party nature of the processes involved, and the > sentiment that a consolidated approach to the problem could do better than > the piecemeal approach. That said, I don't know that we have a clear > enough understanding of the problem space and how to approach it that I > could try to charter a WG to do the work; I think your suggestion of trying > to have the IAB or T2TRG steer that discussion is reasonable, and I can try > to see if the IAB is interested. I am curious, though, how many people on > this list would be willing to put some time into such a discussion. > > Thanks, > > Ben > > On Thu, Sep 19, 2019 at 12:06:13AM -0400, Rene Struik wrote: >> Hi Ben: >> >> Please find below my feedback on the draft charter for LAKE WG, as follows: >> a) Feedback on the draft charter you put forward below. >> b) Gap between "LAKE next steps" on mailing list and actual LAKE BOF >> discussion during IETF-105 in Montreal. >> c) Motivation for tackling a more general scenario. >> {For some earlier discussion on items b) and c) above, see my previous >> emails on this on the LAKE mailing list (condensed below for conciseness)} >> >> Note RS: I am not against chartering this effort, as long as the more >> general scenario is also chartered (where the more general scenario >> would provide a long-term system solution). If there is only one narrow >> effort coming out of the LAKE BOF, I think we are heading in the wrong >> direction. >> >> Ad a): Comments on draft charter you put forward (email Benjamin Kaduk, >> Sep 4, 2019, 12.56am EDT): >> >> In my opinion, the description of the goals should more clearly >> articulate that one keeps an open view with respect to potential >> solutions: currently, this primarily singles out >> draft-selander-ace-cose-edhe ("EDHOC") and any input from the TLS WG as >> targets of evaluation. What about replacing the last sentence of this >> paragraph by the more neutral and open phrase "The WG will also >> evaluate prior work from the TLS WG and derivatives thereof, and >> draft-selander-ace-cose-ecdhe", as used during the LAKE BOF (see >> slides-105-lake-proposed-charter-01). >> >> Having a concise authenticated key agreement scheme (AKC) seems to have >> merit, independent of very specific encoding and compression >> conventions. This makes me wonder whether the core AKC functionality and >> the representation hereof could be described separately, where the >> latter is simply an encoding that could be "stripped". If so, this seems >> to make it easier to implement securely on existing chipsets with crypto >> functionality on board. (Now that we are at this, does OSCORE/COSE have >> sufficient syntax to describe certificate chains?) >> >> Ad b): LAKE next steps on mailing list vs. actual LAKE BOF discussion >> during IETF-105 in Montreal (email RS of Aug 26, 2019, 11.21pm EDT): >> >> From the discussion at the LAKE BoF, it seemed there was strong support >> for also tackling the broader scenario (triggered by David Thaler's >> suggested dichotomy at the microphone). (Note: according to the draft >> LAKE BOF minutes [minutes-105-lake-00], there was strong agreement that >> both OSCORE key exchange (the "narrow" problem) and the broader >> constrained scenario were problems that needed solving, with strong >> willingness work on this (15-17 hands for OSCORE, 10-11 for general >> case, few overlapping). ) >> >> Nevertheless, I have some trouble seeing suggested next steps on >> tackling this broader problem. After I asked on elaboration on how one >> would see this broader topic ("general purpose lightweight AKE") find a >> home in terms of next steps (in my mind, this is not simply "TLS with >> compressed representation"), it was suggested - roughly speaking - that >> TLS was the more general approach. >> >> >> Ad c): Motivation for tackling a more general scenario: >> >> Technically, it seems that ECDHOC and TLS share a similar crypto design >> philosophy, protocol flow framework, and instantiation, where - simply >> put - EDHOC just uses a more concise encoding of an ECDH+Sign (Sigma) >> protocol and cuts some other unneeded wood. >> >> Arguably, the general IoT case cannot presume a Client/Server model, nor >> semi-infinite resources on one of the entities. Moreover, the >> communication path is relatively more costly (both in terms of time, >> routing, network enrollment, and DoS attack surface), and devices may be >> cheap, but should operate securely in a hostile environment, over their >> entire lifecycle, without much user intervention. This calls for a much >> more ambitious approach than an encoding exercise. What is needed is a >> system approach, taking into account the entire device's lifecycle, with >> considerations of threats. >> >> To illustrate that a simple (smartly encoded) AKC is not enough, I will >> consider the use of EDHOC in LoRaWAN, 6TiSCH, and IoT bootstrapping >> considered (for quoted references, see Section 8.7 of >> draft-selander-ace-cose-ecdhe-14 [Note: some analysis may apply to other >> AKCs than ECDHOC as well]). >> >> i) 6TiSCH use case (draft-ietf-6tisch-dtsecurity-zerotouch-join-04): >> It is unclear from the -04 draft how EDHOC would work with 6TiSCH. >> According to the author, the previous 03-draft was "shit", "need[ed] to >> rewrite from scratch" (April 2, 2019); the 04-version had a slot, >> without slides, at IETF-105, but minutes suggest future of draft was >> questioned. My understanding from discussions in the hallway of IETF-105 >> was that intention was to combine the first two flows of EDHOC and then >> simply combine this with the Join-Request and Join-Response command in >> the 6tisch-minimal draft (where, to my understanding, the idea seemed to >> be to "simply" plug-in the computed shared key as shared key in the join >> request/response flows. Just a cautionary remark here: there is much >> more to security and implementability of cryptographic protocols then >> mechanically making protocol flows work by mix-and-matching partial >> flows... the zerotouch draft also mentions lots of other protocol flows >> over many hops (BRSKI, etc.); 6TiSCH also has a parameter exchange >> between JRC (=central manager) and "pledge" (joining node) following >> network enrollment. Conclusion: optimizing the AKC by itself does have >> little impact on system-level device enrollment overhead; a more general >> method might, though. >> >> ii) LoRaWAN ([LoRa1]; [LoRa2] ref not studied since dead link): >> Fig. 3 suggests use of EDHOC to derive key that would subsequently used >> with join request/response (similar to 6TiSCH speculation above). Fig. 5 >> of [LoRa1] paper suggest LoRa has 41-47 bytes header and 71-176 bytes >> for EDHOC. >> >> iii) IoT bootstrapping [Perez18]: >> Bootstrap is followed by ECDHOC (see Section 5.1 (Fig. 3); Section 5.2 >> (EDHOC); Table 1 (Section 7.1 - testbed); bootstrap (7 >> flows)/credentials (2 flows)/EDHOC (3 flows); Fig. 9: total message >> sizes). From the description, tables, and message size comparison, it is >> - again - clear that having an optimized AKC in a sea of unoptimized >> message exchanges is not going to make much of a difference. >> >> Overall conclusion: in all cases, EDHOC overhead seems to be relatively >> small portion of total message size. Moreover, in IoT bootstrapping case >> (iii) and 6TiSCH (i), provisioning, etc. also takes quite large >> overhead. In almost all cases, actual protocols are not 2-party >> protocols, but 3- or more-party protocols (e.g., [with 6TiSCH], Joining >> Node - Neighboring Router part of network - Security Manager (many hops >> away)). This suggests, that one may be well off to design protocols that >> takes more than 2 parties into account, rather than simply having a >> 2-party AKC. >> >> The IETF has many, many drafts focusing on addressing partial design >> spaces (e.g., Anima, NOOB, pwd-based scheme, certiicate enrollment, >> etc.). However, pointwise local minimization does not necessarily lad to >> global minima: designs that take system lifecycle design into account >> may do so, though. This also may allow study of DoS attack issues, that >> usually are tackled by all-powerful devices that IoT simply does not have. >> >> Suggestion: tackle the more general problem, in, e.g., IAB, T2TRG, in >> fundamental way, with suggested blueprint roadmap ~ IETF-107, where >> design team presents more detailed picture in summer 2020. >> >> >> >> On 9/4/2019 12:56 AM, Benjamin Kaduk wrote: >>> Hi all, >>> >>> Thanks to everyone for the feedback so far. In the interest of moving from >>> an informal post-BoF discussion to a more structured path forward, this >>> message starts a two-week last call for comments and consensus on a LAKE >>> charter. I've tried to incorporate the feedback from Martin and Göran >>> (though my editorial hand couldn't resist a few tweaks; all errors are >>> mine), and my apologies to anyone whose comments I missed. Depending on >>> how discussion goes, additional revisions may be posted during the comment >>> period to help achieve better clarity. If we get good agreement here, then >>> the charter can go to the IESG and IAB for the formal approval process >>> (including IETF LC). Please reply even you have no specific comments; the >>> IESG and IAB need to be able to gauge the level of community support for >>> and interest in the proposed work. >>> >>> Thanks, >>> >>> Ben >>> >>> ==[ 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 number of round-trips to complete, >>> 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. draft-selander-ace-cose-ecdhe is a candidate >>> starting point for the LAKE produced by the WG. Any work available from >>> the TLS WG that satisfies the determined requirements will also be >>> evaluated for suitability. >>> >>> 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 ]== >>> >> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [Lake] Lake charter call for comments Benjamin Kaduk
- Re: [Lake] Lake charter call for comments Michael Richardson
- Re: [Lake] Lake charter call for comments Francesca Palombini
- Re: [Lake] Lake charter call for comments Marco Tiloca
- Re: [Lake] Lake charter call for comments Göran Selander
- Re: [Lake] Lake charter call for comments Salz, Rich
- Re: [Lake] Lake charter call for comments ivaylo petrov
- Re: [Lake] Lake charter call for comments Göran Selander
- Re: [Lake] Lake charter call for comments Dan Garcia
- Re: [Lake] Lake charter call for comments Salz, Rich
- Re: [Lake] Lake charter call for comments Göran Selander
- Re: [Lake] Lake charter call for comments Mališa Vučinić
- Re: [Lake] Lake charter call for comments Antonio Skarmeta
- Re: [Lake] Lake charter call for comments Christian Amsüss
- Re: [Lake] [EXTERNAL] Re: Lake charter call for c… Damm, Benjamin
- Re: [Lake] Lake charter call for comments Benjamin Kaduk
- Re: [Lake] Lake charter call for comments Salz, Rich
- Re: [Lake] Lake charter call for comments Rene Struik
- Re: [Lake] Lake charter call for comments Benjamin Kaduk
- Re: [Lake] Lake charter call for comments Rene Struik
- Re: [Lake] Call for adoption for draft-selander-l… Rene Struik
- Re: [Lake] Call for adoption for draft-selander-l… Göran Selander