Subject: [Lake] Lake charter call for comments

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Sep 2019 23:56:54 -0500

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 ]==

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2019 03:16:07 -0400

Benjamin Kaduk <[email-masked]> wrote:
    > ==[ CHARTER ]== Problem

    >   * 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

    > 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.

This text addresses the concerns I had.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 5 Sep 2019 11:48:03 +0000

Hi Ben,

I support this charter.

Nit: 
"(this draft will not be published as an RFC but will be
used to drive WG consensus on the deliverable (2)"
is missing a final parenthesis.

Francesca

On 04/09/2019, 06:57, "Lake on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    Thanks,
    
    Ben
    
    ==[ CHARTER ]==
    Problem

    
    Goals

    
    Program of Work

    
    
    -- 
    Lake mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lake

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 5 Sep 2019 15:44:46 +0200

Hi,

I support this work and the latest charter.

Best,
/Marco

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Göran Selander <[email-masked]>
Date: Thu, 5 Sep 2019 15:59:15 +0000

Hi Ben,

Thanks for taking into account my comments, the proposed charter looks good to me.

Göran

On 2019-09-04, 06:57, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi all,

    Thanks,
    
    Ben
    
    ==[ CHARTER ]==
    Problem

    
    Goals

    
    Program of Work

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Sep 2019 16:50:14 +0000

No mention of minimum security requirements that must be met?

Would we take 1K public-keys or 3DES?

---

From: ivaylo petrov <[email-masked]>
Date: Tue, 10 Sep 2019 09:15:59 +0200

Hello Ben,

I support this work and the proposed charter looks good to me.

Best regards,
Ivaylo

---

From: Göran Selander <[email-masked]>
Date: Tue, 10 Sep 2019 10:16:59 +0000

Hi Rich,

Security requirements are of course part of the requirements activity in the WG. It is not clear to me what additional security requirements we need to put into the charter.

The crypto and key length requirements I can think of in the charter are either more or less obvious or require further analysis. In the obvious category, the LAKE must support the use and negotiation of adequate cipher suite and key lengths, ECC, etc.

Stating in a general way what is an adequate cipher suite and key length seems more difficult to do in the charter. Stanislav Smyshlyaev in his CFRG review of EDHOC [1] raised the question of a suite with P224 as a lightweight alternative. This illustrates a tradeoff between key length and message size, but this is still a question. (I don't propose we put the analysis of such tradeoffs in the charter, but leave this to the WG to analyse, if appropriate.)

Göran

[1] https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ

On 2019-09-09, 18:50, "Lake on behalf of Salz, Rich" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Dan Garcia <[email-masked]>
Date: Tue, 10 Sep 2019 13:57:58 +0200

Hello Ben, all, 

I support this work. The current charter looks ok. 

Best Regards,

Dan García.

De: Lake <[email-masked]> en nombre de ivaylo petrov <[email-masked]>
Fecha: martes, 10 de septiembre de 2019, 9:27
Para: Benjamin Kaduk <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [Lake] Lake charter call for comments

Hello Ben,

Best regards,

Ivaylo

Hi all,

Thanks,

Ben

==[ CHARTER ]==
Problem

Goals

Program of Work

-- Lake mailing list [email-masked] https://www.ietf.org/mailman/listinfo/lake

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 Sep 2019 13:28:25 +0000

Thanks for the answer, it makes sense.

I still think a general statement like "without unnecessarily sacrificing security properties" should be there somewhere.  My intent behind that is that if the WG decides to use ROT13 because some IoT pencils have limited capabilities, this should be explained in the documents.

Does that make sense?

---

From: Göran Selander <[email-masked]>
Date: Tue, 10 Sep 2019 14:02:33 +0000

> 10 sep. 2019 kl. 15:28 skrev Salz, Rich <[email-masked]>:
> 

Indeed. The ambition of the various ongoing activities is to reduce overhead and simplify processing without sacrficing security.

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 10 Sep 2019 18:06:27 +0200

Hi,

I support the proposed charter, it’s great to finally see progress on this topic.

Mališa

> On 4 Sep 2019, at 06:56, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Antonio Skarmeta <[email-masked]>
Date: Tue, 10 Sep 2019 18:20:33 +0200

Dear all

I support also the proposed charter, we will like to work forward on it

regards.

-- 
------------------------------------------------------------
Antonio F. Skarmeta
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
30100 Murcia
Telf: +34-868-884607
fax: +34-868-884151

---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 11 Sep 2019 14:04:00 +0200

Hello Ben,

On Tue, Sep 03, 2019 at 11:56:54PM -0500, Benjamin Kaduk wrote:
> the IESG and IAB need to be able to gauge the level of community
> support for and interest in the proposed work.

The proposed charter looks suitable to produce a document that I'll want
to implement.

Rich does have a good point about "unnecessarily sacrificing security
properties", especially as the Charter will be the entry point for first
impressions to people outside the WG that might have unwarranted
concerns about constraints leading to less than state of the art cipher
suites; a half-sentence on that would help with impressions, but is
probably not necessary for the work based on the charter.

Best regards
Christian

-- 
You don't become great by trying to be great. You become great by
wanting to do something, and then doing it so hard that you become great
in the process.
  -- Marie Curie (as quoted by Randall Munroe)

---

From: "Damm, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2019 16:15:30 +0000

Benjamin,

The charter looks good.

The question of minimum security is one that the WG can address within the protocol produced.

=Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Sep 2019 11:47:24 -0500

> Indeed. The ambition of the various ongoing activities is to reduce overhead and simplify processing without sacrficing security. 

I could toss in a half-sentence (to crib Christian's phrasing) after the
list of what "lightweight" refers to: "but the LAKE must still provide the
security properties expected of IETF protocols".  How would that work?

Thanks,

Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Sep 2019 16:51:17 +0000

That works for me.  Some might want you to add "or explain why not" at the end, but I'm not one of those. :)

---

From: Rene Struik <[email-masked]>
Date: Thu, 19 Sep 2019 00:06:13 -0400

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.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Sep 2019 15:48:57 -0700

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