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

Rene Struik <rstruik.ext@gmail.com> Mon, 22 June 2020 22:36 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 C9A2C3A1248 for <lake@ietfa.amsl.com>; Mon, 22 Jun 2020 15:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=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 dAhqH7AKNQmP for <lake@ietfa.amsl.com>; Mon, 22 Jun 2020 15:36:14 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 DB8F13A1229 for <lake@ietf.org>; Mon, 22 Jun 2020 15:36:13 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id j10so5400806qtq.11 for <lake@ietf.org>; Mon, 22 Jun 2020 15:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=2RhrfRtfTJsjyUVjlbjYaE/uP8LinUa2lHzi5TZLdm0=; b=miR0UKvVZ/TosYcMzzq9jLVuJl+7+tyL7j+6VeQwEOHFZT6BTLnbyqSS9reXkYqH1k o7UUtx2BXmixf6ozW8t5+N8wWfmK9ywC+3KIeIolfASZgNcxG4sehUJD2F4ZS0UccM1E UxkVT6spgWhVqCseTnMfNgSKJi/MQJexm3pffsltTZmctaDZQ7js0oegN/NSosjzlDJl JNTZ4Zy964EhxeGvnOWr1MT+hdi9jaIzT3xdRr8gXVOrZ/xz7REGj/L/0koBrOGIlfdH 6AdqJhx9PaQ8Ftviw+RVxLWAZ2dRGt6Kq+AM2cWTItOaaMdSamOcJB0uQrxXWZQmAZRq SAQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2RhrfRtfTJsjyUVjlbjYaE/uP8LinUa2lHzi5TZLdm0=; b=DJm47rUaLpNlCZ8mo/nivDohIffLFTsXgNXqe5MQF5a8sCwTUoFlJXioSK+Jau0Ohi K1Lygp6Mxiy6t0Hcb+OZgTGxK1eV8EzqBYQ+YJlKx3LcSEFFMcQy1HT6Gbt3x1TYt3CD PNEZcC88HVurN54fUxyUkn40WlpKiK3NhCbRoDEXjdX5FV/dR0DzqEItAaZmLbFxNpy7 KJnpSJ8YgMIAjfNEnh49PhZLwsP7hjr6mKfQntQKtNVeEy48xk30yZDBYdu8UBrLlwy/ 8JqOCLh1gzkFvMTOrOB4EcOLOTgQebpMxDvKBwb+B2YJTOTIsA1qvrJgVeRCZU81xf70 dZ9A==
X-Gm-Message-State: AOAM533GkxhlNezb7wLnL59gYGvg7wssGYz3H5RTN1XiXvXv+FtkSKZU LhfqI1UzG+qRa095iaCK1fUB0rcP
X-Google-Smtp-Source: ABdhPJwB8+lTBUQUbN0/ifVoEWENZogT/J7ItdGIpHFLa0SyAGWmnkyXhavRHWlH1zzydCXRhlhYJQ==
X-Received: by 2002:ac8:6bc1:: with SMTP id b1mr18720427qtt.65.1592865372209; Mon, 22 Jun 2020 15:36:12 -0700 (PDT)
Received: from ?IPv6:2607:fea8:8a0:1397:d1fb:bb54:e45f:560? ([2607:fea8:8a0:1397:d1fb:bb54:e45f:560]) by smtp.gmail.com with ESMTPSA id r76sm14205502qka.30.2020.06.22.15.36.11 for <lake@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jun 2020 15:36:11 -0700 (PDT)
References: <0f8e9d07-ffc0-7a0d-8aba-a3ea65937c1b@gmail.com>
To: lake@ietf.org
From: Rene Struik <rstruik.ext@gmail.com>
X-Forwarded-Message-Id: <0f8e9d07-ffc0-7a0d-8aba-a3ea65937c1b@gmail.com>
Message-ID: <39b11e50-6641-7c2b-6bb4-0da238135a8a@gmail.com>
Date: Mon, 22 Jun 2020 18:36:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <0f8e9d07-ffc0-7a0d-8aba-a3ea65937c1b@gmail.com>
Content-Type: multipart/alternative; boundary="------------9DE22EF2EAFAE06B7FE550F8"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/KGiw6uY5u5J9ANcwbnsaRvqWh1s>
Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - 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: Mon, 22 Jun 2020 22:36:30 -0000

Dear colleagues:

My original assessment, as articulated during the Lake WG charter 
discussion (see [1]) still stands). I suggest rejecting this draft.

It is unclear whether one solves the right problem (apart from whether 
one solves the stated problem right). However, I have already 
articulated this during the rechartering discussion.

In IEEE PAR discussions, there is a requirement to describe a "why 
should one care" justification for an effort, where - if one would do 
this with IETF Edhoc - the justification seems to be "we can use 
slightly smaller enodings" than with, e.g., DTLS or with TLS, while 
reusing virtually all of the same crypto protocol flows, construct 
details, etc. Question is whether this is enough.

Some pain points of the draft (imho):

-- lack of flexibility and consideration of the entire lifecycle. Lots 
of rosy counting techniques for message flows do not hold up if one does 
not use "bare minimum" settings (e.g., by having certs instead of raw 
public keys that are assumed pre-installed); wants to have better DoS 
attack resiliency (where having only three flows does not help at all, 
etc). These also completely brush away the message flows required for 
provisioning (it may very well be that provisioning of each device takes 
more message flows than the, essentially, authenticated key agreement 
scheme, where co-design would have enabled one to design a set of 
protcols where one optimizes for total cost, rather than piecemeal 
minima. {As a side note, did one consider what, e.g., using "NOOB" [2] 
with EDHOC entails in terms of message flows, latencies, etc.?

-- lack of support for reusing implementations, where hardware/software 
co-design may not have support for encodings/decodings (and where this 
now has to be included in the trusted platform boundary). It is unclear 
whether engineering and certification headaches have been carefully 
assessed. It is also unclear whether the complementary part of the 
system lifecycle now is also forced to use all the same 
encoding/decoding, etc. (an ossification risk by itself).

-- unclear trade-off communication cost vs. computational cost: here, I 
will simply refer to the very expensive method that uses a static-DH key 
(it leads to size savings, but significantly increases computational 
cost and, there, also DoS risk).

Some other questions:

-- why does one need both signature-based and static-DH-based methods. 
If the objective is to be lean, then having many Chinese menu options 
(term credited to Peter Gutman) does not help.

-- some of the ciphersuite recommendations are somewhat odd. Having 
co-authors of this draft advocate EdDSA, while claiming this to be 
insecure (given easy fault attacks, esp, in IoT-setting?), in 
draft-mattsson-cfrg-det-sigs-with-noise-02 seems to be inconsistent. Why 
not simply use ECDSA (if one wishes ECDSA25519) and suggest a 
non-clamped version of ECDH (like all the co-factor ECDH schemes apart 
from RFC7748 do.? Why not supporting NIST curves, why enforcing both 
SHA512 and SHA256 at the same time, why pure-EdDSA (which requires two 
data passes), etc.?

Overall, I think pursuing this draft seems to leave too many questions 
to be answered to allow a positive verdict.

I know this draft has been pursued for quite a long time, but there are 
too many fundamental questions that are unanswered and it is unclear 
what design motivations really have been (except for low message size 
counts in an optimistic table). I suggest therefore there is no reason 
to adopt this.

My comments as during the chartering exercise also still stand.


Ref: [1] 
https://mailarchive.ietf.org/arch/msg/lake/EOpWc97_wtku5mVTtztTsJlhCks/
{See also below for copy of that e-mail RS to Benjamin Kaduk/Lake WG 
email list;  Thu Oct 3, 2019, 11.14am EDT, Subject Re: [Lake] Lake 
charter call for comment] }
[2] draft-aura-eap-noob-08

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