Re: [Lake] Lake charter call for comments

[Rene Struik <[e-mail]>]

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: [e-mail] | Skype: rstruik
>> cell: [phone] | US: [phone]
>>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]