[Lake] FW: 1 week 2nd WGLC on requirements and scoping text

[Göran Selander <[e-mail]>]

From: Lake <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Date: Tuesday, 2 June 2020 at 03:19
To: Stephen Farrell <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Lake] 1 week 2nd WGLC on requirements and scoping text



On Sun, May 24, 2020 at 2:08 PM Stephen Farrell <[e-mail]<mailto:[e-mail]>> wrote:

Hi all,

First: my apologies for taking so long on this. (I got
sidetracked by an unexpected project.)

ISTM we have pretty good, if rough, consensus on enough of
the text to proceed, but with one important part that needs
checking. (See below.)

I'd like to start a 1 week 2nd WGLC with the main focus
being to establish whether we have rough consensus on the
scoping text below. (Which can be see in context at [2].)
That text was the main outcome of our virtual meeting last
month.

So, please send mail to the list saying if you are happy
enough to proceed on this basis. If you are not, then I'd
appreciate if you could suggest alternate text with as
few changes as possible.

This 2nd WGLC closes on June 1st. If I see rough
consensus to proceed at that point, I'll plan to start a
call for adoption for the edhoc draft. If not, we'll have
to discuss how to proceed with our AD, as I think that
would mean that the WG is very badly stuck.

The scoping text added was:

   As illustrated above, the setting is much more diverse
   in terms of credentials and trust anchors than that of
   the unconstrained web.  In order to deliver a timely
   result, there is a need to initially focus on what is
   considered most important at the time of writing: RPK
   (by reference and value) and certificate by reference.
   Information about validity of a certificate may be
   omitted from the AKE if available over unconstrained
   links.  The case of transporting certificate validation
   information over the AKE may be specified in the initial
   phase if there is a lightweight solution that matches
   existing standards and tools.

   A subsequent extension beyond the initial focus may be
   inevitable to maintain a homogenous deployment without
   having to implement a mix of AKE protocols, for example,
   to support the migration path described above.  The AKE
   needs to make clear the scope of cases analysed in the
   initial phase, and that a new analysis is required for
   additional cases.

Stephen

It's not clear how to read this in the context of other parts of
the document, for instance: https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2
which says:


   In order to allow for these different schemes, the AKE must support

   PSK- (shared between two nodes), RPK- and certificate-based

   authentication.  These are also the schemes for which CoAP is

   designed (see Section 9 of [RFC7252]<https://tools.ietf.org/html/rfc7252#section-9>).

How is one supposed to interpret this text?




[GS] Since OSCORE is an extension to CoAP it is expected to support the schemes for which CoAP is designed. But in the discussion following the virtual IETF 107 LAKE WG meeting we restricted the initial focus, leading to the addition of section 2.2.1 and the following text in the paragraph after the one you quoted:

”In order to provide a clear initial effort, Section 2.2.1<https://www.ietf.org/id/draft-ietf-lake-reqs-03.html#initial-focus> lists a set of credential types of immediate relevance; the mechanism for selecting credential scheme is presumed to enable future extensibility if needed.”

The ability to extend beyond the initial focus is also repeated in the text from Section 2.2.1 which Stephen quoted in his mail:

”A subsequent extension beyond the initial focus may be inevitable to maintain a homogenous deployment without having to implement a mix of AKE protocols, for example, to support the migration path described above.”

It seems to me that the working group has a sufficient good understanding and support for where to start this work and to allow for extensibility, so I propose we do just that.

We may in parallel make clarifications to the requirements as needed. In fact, I expect we will revisit the requirements throughout the work as more insights are gained, potential inconsistencies discovered, etc., but that should not stop us from moving the work forward now.

Göran


-Ekr


Thanks,
Stephen.

[1] https://tools.ietf.org/html/draft-ietf-lake-reqs-03
[2] https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2.1

--
Lake mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lake