Re: [Lake] Lake charter call for comments

[Benjamin Kaduk <[e-mail]>]

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