Re: [Lake] March 31st virtual interim minutes

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

All,

I read the minutes and was reminded of some things that were not adequately highlighted at the meeting. (Not saying that the minutes are wrong, but the underlying arguments may not always be easy to follow.)  Some comments below.

"if EDHOC is going to be only solution by this working group, requreiemtns are secondary"

Note that the current charter says there is going to be *at most* one solution in LAKE. Note also that CTLS is already adopted in the TLS WG, and it does not have to comply with the LAKE requirements. Putting the current charter in context there are essentially two alternatives: Either we adopt a solution complying the LAKE requirements or we close down LAKE.

"existence proof"

I think this refers to section 2.10.4 where it says that it is possible to design PSK ECHDE and RPK ECDHE with 3 messages that fits into 1 fragment per message for the benchmarks.

"it is unhealthy for IETF to standardize a large pile of AKEs"

One thing I think is unhealthy is that we don't have a lightweight AKE to key constrained IoT deployments. The problem is not that there are too many AKEs in the IETF and that we don't know which to choose. The problem here is that there is no RFC or adopted AKE that is lightweight in the sense of the LAKE requirements.

While it is not an objective to make LAKE a general purpose AKE, the scope of LAKE should be driven by the use cases, the lack of other solutions, and the ability to reuse LAKE as the security setting change, see migration path in section 2.2. The whole point here is to simplify for developers when moving away from PSK to other settings without having to replace the implementation of one AKE with another.

Having said this, we can and should still reason about the importance of the different settings as in "Ben's proposal for a way forward". One important case that was mentioned by Michael in the meeting but not captured in the minutes is the requirement to support certificates by reference. Clearly certificates are important for many IoT settings e.g. facility management with a large number of devices from many different manufacturers. But, as was mentioned in the meeting, transport of certificate chains is not expected the be lightweight and therefore of less priority.

Göran


On 2020-04-03, 15:52, "Lake on behalf of Mališa Vučinić" <[e-mail] on behalf of [e-mail]> wrote:

    Hi all,
    
    Thank you for attending the meeting on Tuesday. We uploaded the minutes at [1]. If you see any errors, please let the chairs know. 
    
    I have also created the github issues corresponding to the action points on the requirements draft [2]. Let’s aim at having these completed by April 17th, 2020.
    
    We will follow up shortly with the next steps and the Ben’s proposed text for a way forward.
    
    Mališa
    
    [1] https://datatracker.ietf.org/meeting/interim-2020-lake-03/materials/minutes-interim-2020-lake-03-202003311800
    [2] https://github.com/lake-wg/reqs/issues
    
    
    
    
    
    -- 
    Lake mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lake