Re: [Lake] Lake charter call for comments

[Rene Struik <[e-mail]>]

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]