# Lightweight Authenticated Key Exchange (LAKE) - Interim   {#lightweight-authenticated-key-exchange-lake---interim}

## Wednesday, 5 October 2022 -- 15:00-16:00 UTC   {#wednesday-5-october-2022--1500-1600-utc}

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

*   Mališa Vučinić
*   Stephen Farrell

### Notetakers   {#notetakers}

*   Marco Tiloca (thanks!)

### Participants   {#participants}

*   Stephen Farrell
*   Mališa Vučinić (Inria)
*   Marco Tiloca (RISE)
*   Carsten Bormann (TZI)
*   Göran Selander (Ericsson)
*   John Preuß Mattsson (Ericsson)
*   Jonas Primbs
*   Loïc Ferreira
*   Rikard Höglund (RISE)

### Useful Links:   {#useful-links}

*   [Charter][1]
*   [Mailing list][2]
*   [Instant Messaging][3]
*   [Minutes][4]
*   [Remote participation][5]

### Agenda   {#agenda}

*   Administrivia  
    -- chairs, 5 mins
*   draft-ietf-lake-edhoc-16  
    -- John Preuß Mattsson & Göran Selander, 25 mins
*   draft-ietf-lake-traces  
    -- Marco Tiloca, 10 mins
*   Remaining issues  
    -- Göran Selander, 10 mins
*   Ready for WGLC?  
    -- chairs, 10 mins
*   AOB

### Minutes   {#minutes}

*   Administrivia  
    -- chairs, 5 mins

MV doing introduction

*   draft-ietf-lake-edhoc-16  
    -- John Preuß Mattsson & Göran Selander, 25 mins
    *   Presented slides:
        https://datatracker.ietf.org/meeting/interim-2022-lake-02/materials/slides-interim-2022-lake-02-sessa-edhoc-16-and-remaining-issues-00
    *   GS: Just submitted v -16
    *   GS (p4): Few major changes are due to the security analysis:
        computing of PRK\_2e, TH\_3 and TH\_4. Multiple minor changes,
        more as clarifications and not affecting the main protocol. A
        new appendix defines how to handle a large EDHOC message\_2.
    *   GS (p5): First major change, TH\_2 is used as salt for computing
        PRK\_2e.
    *   GS (p6): Second major change, using CRED\_R/CRED\_I as
        additional third argument for computing TH\_3/TH\_4.
    *   GS (p7): On handling a large message\_2, if its size passes 255
        \* hash\_size and a hash function is used for HKDF-Expand. in
        this case, KEYSTREAM\_KEY is computed in chunks, with each chunk
        intended to be XORed with a corresponding chunk of PLAINTEXT\_2.
        As a side effect, the label for EDHOC-KDF had to be redefined as
        signed integer. For a PLAINTEXT\_2 not that big, this becomes
        the main case defined in the document body.

*   draft-ietf-lake-traces  
    -- Marco Tiloca
    *   Presented slides:
        https://datatracker.ietf.org/meeting/interim-2022-lake-02/materials/slides-interim-2022-lake-02-sessa-draft-ietf-lake-traces-00.pdf
    *   Quick update on ongoing work. PR#337 aligns with edhoc draft-16.
        Would love feedback. Planning to do some interop next few weeks
        and/or in London @ IETF-115. Then... *very* careful checks,
        merge and publish traces draft-03, which'll hopefully be the
        final version.
    *   Q (MV): state of other implementations?
    *   MT: not sure
    *   GS: Marek has put test vectors on the Github, with certificates
        as authentication credentials. It's good if you can interop,
        focusing on the test vectors related to the traces first.
    *   MV: my Rust code should be ready for London

*   Remaining issues  
    -- Göran Selander, 10 mins
    *   Presented slides:
        https://datatracker.ietf.org/meeting/interim-2022-lake-02/materials/slides-interim-2022-lake-02-sessa-edhoc-16-and-remaining-issues-00
    *   https://github.com/lake-wg/edhoc/issues
    *   GS (p10): issue #324 on achieved security level. ENS proposes a
        change to the key schedule; this increase the security level
        against online attacks, but complicates other precessing. The
        same results can be differently achieved by verifying multiple
        MACs, see #340. An example building on this is also the
        EDHOC+OSCORE combined request in draft-ietf-core-oscore-edhoc.
        We propose to take the latest direction of issue #340.
    *   JPM: So no technical changes, things are better than the current
        EDHOC draft may suggest. If EDHOC message\_4 is replaced by the
        OSCORE message, some more processing has to be added for
        terminating EDHOC in case of failed MAC verification.
    *   MV: If message\_4 is used the security level is >=128 bits,
        correct?
    *   GS: Against online attacks.
    *   JPM: It's the sum of the security level you get from message\_3
        and message\_4.
    *   MV: And same if the OSCORE message is piggybacked?
    *   GS: Yes.
    *   SF: Are you going to recommend this? It might be difficult for
        some implemetations in terms of layer violation.
    *   JPM: No plan for recommending, you may be fine with what you
        have. It's more a suggestion for a possible thing to do to
        achieve a certain results.
    *   GS (p11-12): issue #338, based also on discussions in CoRE,
        there seems to be no use of EDHOC-KeyUpdate(). It was first used
        in KUDOS (draft-ietf-core-oscore-key-update), but it got removed
        in the interest of keeping only one, simpler construction. There
        is another ACE document that would actually make use of
        EDHOC-KeyUpdate. Regardless, we propose to move
        EDHOC-KeyUpdate() to an appendix in the next version, as not
        fundamental for the protocol. Today we say one SHOULD implement
        EDHOC-KeyUpdate(); with this change it would become just
        OPTIONAL.
    *   SF: Keep it as an appendix, to avoid problems with BCP 107 / RFC
        4107.
    *   GS: I will confirm this on the mailing list.
    *   GS (p13): issues #322 and #329 about security and privacy
        considerations. Plan to address both in the next version based
        on input from reviewers.
    *   GS (p14): more minor issues #326, #142 and #50; proposal: close
        them with no changes.
    *   GS (p15): Plan to submit v -17 before the IETF 115 cut-off, then
        hoping for WGLC.
    *   MV: So, v -17 would close all the current Github issues?
    *   GS: Correct.
    *   MV: Any more issues to raise?
    *   (none heard)

*   Ready for WGLC?  
    -- chairs, 10 mins
    
    *   MV: Fine to start WGLC right after the cut-off?
    *   GS: No big things are happening right now. Big points have been
        accommodated already in the recents PRs.
    *   MV: Looks like we're ready for WGLC.
    *   SF (on chat): Good for WGLC ending at end of IETF 115.
    *   GS: At IETF 115, we can present some comments up until the
        meeting, but it's better if we have the WGLC before then, so
        that we can work on it at IETF 115.
    *   SF: To give 2 weeks to review, can you submit on October 17th
        latest?
    *   GS: Yes.
    *   MV: So we wrap-up on Oct 17, then we start the WGLC for 2 weeks,
        and we work on the results at IETF 115.

*   AOB
    *   SF: If WGLC is smooth as I hope, if people want to re-charter,
        that would be a good time to bring up suggestions. Otherwise, we
        declare victory and close after that.
    *   JPM: Also taking into account the -traces document.
    *   SF: Yes.



[1]: https://datatracker.ietf.org/group/lake/about
[2]: https://www.ietf.org/mailman/listinfo/Lake
[3]: https://zulip.ietf.org/#narrow/stream/11-lake
[4]: https://notes.ietf.org/notes-ietf-interim-2022-lake-02-lake
[5]: https://ietf.webex.com/ietf/j.php?MTID=mb000829604ea8a5986caebf2f46503fc