# Lightweight Authenticated Key Exchange (LAKE) - Interim Meeting

## Tuesday, December 15th, 2021 -- 18:00 - 19:00 UTC

### [Chairs](mailto:lake-chairs@ietf.org):

* Mališa Vučinić
* Stephen Farrell

### Present

* Mališa Vučinić, Inria (MV)
* Stephen Farrell, TCD (SF)
* Carsten Bormann, TZI (CB)
* Marco Tiloca, RISE (MT)
* John Preuß Mattsson, Ericsson (JM)
* Rikard Höglund, RISE (RH)
* Ira McDonald, High North Inc (IM)
* Göran Selander, Ericsson (GS)
* Sean Turner (ST)
* Stefan Hristozov (SH)
* Loïc Ferrera (LF)
* Uri Blumenthal (UB)

### Useful Links:

* [Charter](https://datatracker.ietf.org/group/lake/about)
* [Mailing list](https://www.ietf.org/mailman/listinfo/Lake)
* [Jabber room](xmpp:lake@jabber.ietf.org)
* [Minutes](https://codimd.ietf.org/notes-ietf-interim-2021-lake-05-lake)
* [Webex](https://ietf.webex.com/ietf/j.php?MTID=me537335f0364ae8993f92970a387a9c5)

# Action Points

* Chairs: Start/resume a thread about issue #22 on the list
* Chairs: Start a poll to schedule the next interim for mid-end January 2022.

# Notes

(meetings starts 19:06)

* Administrivia and Agenda Bash -- chairs, 5 mins

* Update on formal analysis call -- Mališa Vučinić, 5 mins
    * MV: Version -12 declared ready for formal analysis, news spread around. France+Germany team doing symbolic analysis with Tamarin and Proverif. For crypto, two teams are on it, some feedback expected in IETF 113 timeframe.
    * SF: Not seen many comments on the overview document starting this.
    * MV: It'll be published in some venue. Comments are welcome.

* draft-ietf-lake-edhoc -- Göran Selander & John Mattsson, 30 mins

    * GS presenting: https://datatracker.ietf.org/meeting/interim-2021-lake-05/materials/slides-interim-2021-lake-05-sessa-edhoc-traces-consolidated-00.pdf

    * GS: no changes to the draft, only on the GH branch with issues and PRs.
    * GS: 5 reviews, 3 of which closed/merged (p3). More issues remain (p4).

    * JM: On issue #213 "Security considerations on Connection IDs", some work is also ongoing in CoRE in the KUDOS draft to (re-)negotiate those https://datatracker.ietf.org/doc/draft-ietf-core-oscore-key-update/
    * Feature not in the draft yet; presented at https://datatracker.ietf.org/meeting/interim-2021-core-14/materials/slides-interim-2021-core-14-sessa-key-update-for-oscore-kudos-00.pdf

    * GS: (p5) re-explained the point about ciphersuites to support (0 and 1) or (2 and 3)
    * MV: "Constrained" device is not really defined. "Endpoint" seems confusing. Why not "device"? What does "or" mean in this context?
    * GS: Some devices support only EdDSA, so they have only ciphersuites 0 and 1. Some devices support only ECDSA, so they have only ciphersuites 2 and 3.
    * MV: When does interop break?
    * GS: If a constrained device supports only 0 and 1, while the other peer is also a constrained device supports only 2 and 3.
    * SH: If 0 is supported, there is no reason to support 1. If 2 is supported, there is no reason to support 3.
    * GS: This is getting to issue #22, for which reaching agreement was postponed.
    * MV: Still important to nail this down for formal analysis and implementors.
    * GS: So we should take a decision on issue #22 at the next interim?
    * MV: Yes, it seems so.
    * GS: The difference from the current -12 is 0->(0 AND 1) and 2->(2 AND 3).
    * MV: Fine to not reopen the discussion today, but keep in mind this is for constrained devices with things to optimize and security properties.
    * CB: The decision on #209 on p5 is uncontroversial.
    * CB: The other decision on #22 about what signature scheme is MTI is interesting and orthogonal. My take is that on constrained devices people will use whatever they want and have available. The risk of non-interoperating is just not possible to prevent altogether. Another question is if we have a preference.
    * MV: Not super pressing, but in the interest of formal analysis.
    * SF: Not that we necessarily have to decide on this, implementors would do whatever they want anyway. We can also bring this topic on the list.
    * Uri (on chat): Vendors that want to claim conformance to "an RFC", usually implement the necessary minimum, and either omit or charge more for "optional" stuff. I'd rather avoid 256-bit cipher suits being in that category
    * GS: Can't reach an agreement today, but we need it soon.
    * SF: Let's revisit the topic on the list.
    * MV: Yes, if we don't reach a conclusion, let's have it at the next interim.
    * --> ACTION FOR CHAIRS: Start/resume a thread about issue #22 on the list
    * GS: (p6) clarified order of events when using EAD, e.g., in EAD use cases.
    * SF: Good to have good security considerations on these points.
    * GS: (p7) more issues, all handled
    * MT: On the possible padding, it should be easier to say OPTIONAL to use for the sender, while mandatory to support in general (since it might be encountered by the receiver). There is an inline comment in a PR about this.
    * GS: Sounds good.

    * GS: (p8) more issues, also handled. We plan to send a summary and request for confirmation on the mailing list.
    * GS: (p9) IANA related comments from Kathleen, they need to be addressed.

    * GS: (p11,12) comments from Sean's review.

* draft-ietf-lake-traces -- Göran Selander & John Mattsson, 15 mins

    * GS: Recently adopted, under discussion what to include at what detail.
    * GS: (p10) Thinking to have one set of traces per method. Across them, we can have variations on a number of things.
    * CB: There shouldn't be anything in the document that is not shown in at least one trace.
    * GS: That's a bit hard to apply, since many things come from COSE for instance.
    * JM: Many more traces are on Github, just not in this draft.

* Next steps -- chairs, 5 mins

    * GS: Finish addressing reviews, close issues/PRs, update the traces.

    * SF: Will send a few mail to the list and a poll for the next interim.

    * --> ACTION FOR CHAIRS: Start a poll to schedule the next interim for mid-end January 2022.

* AOB
    * None