Subject: [Lake] WG process beyond requirements

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jan 2020 15:56:07 +0000

Hiya,

(First - a reminder that we're not using today's virtual
interim slot that would have been in <5 minutes:-)

We've been making fairly good and harmonious progress
on improving the text in the requirements draft [1] which
is great. Our charter calls for us to not publish that
as an RFC, so once we think we're ready (which is not
today) we'll start a WGLC for the draft to establish
whether we've gotten that to a point where we do have
rough consensus on requirements.

We'd like to ask the WG how people would like to proceed
after that point, not to decide that right now, but
mostly to get input and ideas and so we (as chairs) don't
surprise anyone after we hopefully declare victory on the
requirements in the not-too-distant future.

So, your suggestions are welcome...

Thanks,
M&S.

[1] https://tools.ietf.org/html/draft-ietf-lake-reqs

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jan 2020 15:18:16 -0500

> rough consensus on requirements.

This sounds great.

    > requirements in the not-too-distant future.

Good.

(I thought someone should reply so that you'd know your mic was on)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Göran Selander <[email-masked]>
Date: Fri, 24 Jan 2020 18:58:52 +0000

Hi,

Indeed, it seems we are concluding on the requirements. And it is not like we come out the requirements process with a completely new landscape. The current set doesn't seem like a big surprise to anyone, which is good.

As mentioned in the meeting, we must get going with the solution now for several reasons. Companies are waiting for a key exchange to deploy with OSCORE, and the process has already been very long. Earlier IESG input has been to not get stuck in requirements and to work on a solution in parallel. In fact, some of the remaining issues are better discussed in the context of a given protocol, for example, for the recent topic on what kind resumption to specify a comparison of message sizes between PSK-ECHDE and PSK-FS may be a necessary data point to make a decision. 

I think it is the right estimate of the charter milestones to not set aside too much time between WGLC of requirements and adoption or defering to existing solution. With this in mind we need to have all solution candidates on the table in Vancouver.

How about everyone that wants to propose a candidate solution gets a slot in Vancouver to present 
a) how the protocol complies with draft-ietf-lake-req
b) the message sizes using draft-ietf-lwig-security-protocol-comparison as a basis for comparison

Göran

On 2020-01-23, 16:56, "Lake on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    Hiya,

    

    Thanks,
    M&S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Jan 2020 20:33:51 +0000

Hiya,

Thanks. I get the frustration that people working on this
for some time may have experienced, and do want to avoid
making that worse.

That said, I do wonder about this bit:

On 24/01/2020 18:58, Göran Selander wrote:
> How about everyone that wants to propose a candidate solution gets a
> slot in Vancouver to present a) how the protocol complies with
> draft-ietf-lake-req b) the message sizes using
> draft-ietf-lwig-security-protocol-comparison as a basis for
> comparison
Of course if that's what everyone wanted, that'd what we'd
do, but:

- I'd be pleasantly surprised if we're done with WGLC on
the requirements before Vancouver - if everyone finishes
the actions promised and closes issues really quickly,
and if nobody finds any new issues during WGLC, we might,
but that seems a little optimistic

- But more importantly, your suggestion above seems a bit
too much like asking for a competition in March - my guess
is that that could be counterproductive in that it'd be
likely to cause the set of WG participants to split into
groups supporting one proposal or another and make those
groups antagonistic towards each others' proposals.

So, I'd hope we can find something that works, doesn't
slow us down, but maintains the spirit of co-operation
we've seen so far in the WG.

Cheers,
S.

---

From: Göran Selander <[email-masked]>
Date: Tue, 28 Jan 2020 14:02:20 +0000

Hi,

Sorry for the slow response.

On 2020-01-24, 21:34, "Lake on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    your suggestion above seems a bit

I also would like to maintain the good collaboration. Looking at the charter, the next milestone is:

May 2020 	Adopt solution document or defer to existing external solution document

If we can reach this milestone in a good spirit of co-operation, that would be grand. But we need to reach it even if that isn't possible. A much worse outcome would be that we delay this milestone. For those of us who are working on solutions in this space, this milestone creates a large uncertainty as to what the solution will look like and that has a huge impact on the work. So, we definitely don't want to delay this milestone.

Here is how I see the alternatives for the milestone. As we don't have the time frame for a clean slate approach, we need to start with an existing protocol. If only one candidate is put forth, then this milestone is easy. If there are more than one candidate, the only way I can think of to make a decision is to compare them side by side using at least requirement compliance and message sizes as evaluation parameters. In order to reach the milestone before IETF 108, we'd like to start analyzing the alternatives at IETF 107. Even if we many get comments on the requirements in WGLC, I think we should reserve time at IETF 107 to start discussing the solution candidate(s) and how to reach the milestone. As mentioned previously, some of the detailed requirements actually need to be analysed in the context of the solution.

Göran

---

From: Joel Höglund <[email-masked]>
Date: Tue, 28 Jan 2020 16:00:18 +0100

Hi!

We at the RISE security lab are working with key management solutions
related to the work done in LAKE, and we are interested in progress in the
area. Hence we support Göran Selander's wish to proceed, with co-operation,
but without delaying the upcoming milestone.

Best Regards

Joel Höglund

> On 2020-01-28, 15:02, "Göran Selander" <[email-masked]>
> wrote:
>
>     Hi,
>
>     On 2020-01-24, 21:34, "Lake on behalf of Stephen Farrell" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     If we can reach this milestone in a good spirit of co-operation, that
> would be grand. But we need to reach it even if that isn't possible. A much
> worse outcome would be that we delay this milestone. For those of us who
> are working on solutions in this space, this milestone creates a large
> uncertainty as to what the solution will look like and that has a huge
> impact on the work. So, we definitely don't want to delay this milestone.
>
>     Here is how I see the alternatives for the milestone. As we don't have
> the time frame for a clean slate approach, we need to start with an
> existing protocol. If only one candidate is put forth, then this milestone
> is easy. If there are more than one candidate, the only way I can think of
> to make a decision is to compare them side by side using at least
> requirement compliance and message sizes as evaluation parameters. In order
> to reach the milestone before IETF 108, we'd like to start analyzing the
> alternatives at IETF 107. Even if we many get comments on the requirements
> in WGLC, I think we should reserve time at IETF 107 to start discussing the
> solution candidate(s) and how to reach the milestone. As mentioned
> previously, some of the detailed requirements actually need to be analysed
> in the context of the solution.
>
>     Göran
>
>
>
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jan 2020 15:03:15 +0000

Hiya,

On 28/01/2020 14:02, Göran Selander wrote:
> If only one candidate is put forth, then this milestone is easy. If
> there are more than one candidate, the only way I can think of to
> make a decision is to compare them side by side using at least
> requirement compliance and message sizes as evaluation parameters.
Just as an alternative to consider (i.e., I'm not saying I
think this is best, just that it's a possibility), the lake
wg could also adopt a draft e.g. if only one (like edhoc)
were on offer, but remain open to e.g. ctls turning up later,
whenever work on that is completed by the tls wg, which is
likely some time ahead I'd say.

IOW, adopting a draft soonish (when the requirements are done
WGLC), doesn't mean that we need all possible designs that'll
ever meet the lake requirements to be at the same stage of
development in the very near term.

Cheers,
S.

PS: I'd bet its clear but whatever way folks want the WG
to proceed, I hope we can avoid a "mine's better than
yours" competition... if we can:-)

---

From: Göran Selander <[email-masked]>
Date: Tue, 28 Jan 2020 16:08:53 +0000

Hi,

On 2020-01-28, 16:03, "Stephen Farrell" <[email-masked]> wrote:

GS: I'm all in favor of adopting a candidate fulfilling the requirements as a start and decide on other candidates later. But this is a new turn. One year ago in Secdispatch we were requested to define relevant benchmarks and then to formulate requirements, both of these activities were intended for making comparisons between different protocols. Perhaps that is water under the bridge now.

Göran

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Jan 2020 12:47:00 -0500

Göran Selander wrote:
    > would be grand. But we need to reach it even if that isn't possible. A
    > much worse outcome would be that we delay this milestone. For those of
    > us who are working on solutions in this space, this milestone creates a
    > large uncertainty as to what the solution will look like and that has a
    > huge impact on the work. So, we definitely don't want to delay this
    > milestone.

I agree.

I hope that we don't wind up with too many meeting conflicts.