# IETF109 Lightweight Authenticated Key Exchange (LAKE)

Monday November 16th, 0500-0700 UTC

Chairs: Mališa Vučinić, Stephen Farrell
Charter: https://datatracker.ietf.org/group/lake/about
Mailing list: https://www.ietf.org/mailman/listinfo/Lake
Jabber room: lake@jabber.ietf.org
Etherpad: https://codimd.ietf.org/notes-ietf-109-lake
Meetecho link: https://meetings.conf.meetecho.com/ietf109/?group=lake&short=&item=1

Agenda:
- Administrivia and agenda bash (chairs, 5 mins)
- Changes in EDHOC-02 (John Mattsson, 5 mins)
- Open Issues (John Mattsson, 40 mins)
- Planning EDHOC Interop (Francesca Palombini, 15 mins)
- AOB
    - Goran to lead the slot on related work at IETF109

Minutes:
- Administrivia and agenda bash (chairs)

(meeting started at  xx:03.)
* There has been a bunch of discussion in the github repo issues, but not everyone has been clued into this, and so the chairs are letting people know that this is occuring.
    * MCR requested that chairs do the right buttons from git RFC to send weekly updates. https://github.com/dontcallmedom/github-notify-ml

- Changes in EDHOC-02 (John Mattsson)
    - John presents the slides

- Open Issues (John Mattsson)

    * Agreement/negotiation of parameters (#11, #23)
         * MCR suggests that we have an appendix that gathers all the MUST be Agreed Beforehand into one place as a template applicability statement so that users can get it one place.
    * Rekeying OSCORE AEAD (#20)
         * MCR asks how the calculations differ between doing this in EDHOC vs OSCORE
         * SF asks that the Rekeying stuff could go into a developer friendly place to explain when/how/why they need to rekey, so that they do rekey, but not too often.
         * BK says that the CCM_8 are quite low, and do TLS WG is saying, "don't do that", but IoT will be using CCM_8, so we need to deal with this.
         * BK says it comes up in DTLS, because it is AKE, and Record algorithm, so they can just "do it", while in EDHOC/OSCORE, we have split the two pieces.
         * I feel that limits on AEAD key use should be discussed here rather than in CORE because LAKE is in the SEC area, and this is clearly a topic that should have security review.
         * MCR says that it seems to be many people agree that this should be discussed in LAKE.
    * Future Proofing EDHOC (#19)
        * Sean Turner asks how widely implemented is KMAC?  
        * if one uses SHAKE, then one has KMAC. 
        * similiar discussion in CFRG about HPKE: CFRG decided not to mention KMAC, but to make it general in terms of extract/expand.
        * SF: Is there any reason why the answer should be different between EDHOC and HPKE?  John: Nope. SF: Then they should be the same?  
        * MCR: seems like CFRG has caught up, and historically, the HPKE was too new, so now it doesn't matter?
        * Timothy Claeys: wonders about difference between HMAC-SHA2 and KMAC-SHAKE software implementations?
        * The idea is to decrease the complexity for someone that only wants to support SHAKE, they would not need HMAC(-SHAKE). 
    * Future Proofing EDHOC (#17)
        * okay, for #17, "ASK CFRG".  Note that we said that PQC is out of scope in the charter.
        * Tero suggests that the sooner we use latest framework of specifying things (analog to issues with when we moved to use AEAD earlier for SecSH, IPsec, TLS etc), the better the structure is, and we do not end up with problems because we use things that are not allowed by future algorithms only supporting new framework.
        * No objections to this idea.
    * More ways to identify certificates (#32, #33)
        * MCR says that if you can assign a useful kid that fits into ~1byte, then you have to assign the kid somehow, and if you can do that, then you can just use RPK.  MCR suggests that ace-ake-authz solves the problem.
        * BK re-explains this.
        * ongoing discussion about the one-touchness required to use kid.
    * Verification of intended peer (#8)
        * BK: Using EUI-64 as identity is going to get pushback on privacy grounds, from IETF-wide and IESG reviewers
        * BK: But "pushback" of course is not a blanket prohibition, especially if there is a good story around it
        * MCR: so, I think that this is mostly about network->device verification.  I don't see how it works in the other direction, or in the device<->device direction.  So this is a bit of certificate stuff for RPK, and seems like a needless complexity.
        * obviously, you can't randomize the EUI-64, but this EUI-64 is never transmitted. The on-the-wire IID and MAC-address might be randomized.
        * Tero Kivinen: There is no current plans for the IEEE 802.15.4 for supporting privacy addresses, i.e., changing EUI-64 L2 addresses.
        * I would like to think about this topic some more.  Maybe in 802.15.4/802.15.9 then it might make sense. Tero?
    * Resumption (#25)
        * When we removed the PSK, we also removed possibility of doing resumption.
        * Mohit mentions that he feels sad to lose it, but doesn't have a use case today.
    * Distinguish error message (#30)
        * Reported by Stefan Hristozov.
    * ID encryption in message_2 (#34)
        * BK: My suggestion for DTLS 1.3 roughly corresponds to item (3) here.
        * CA: Is the difference between 2 and 3 anything but a formality, at least until we encounter an algorithm where 2 doesn't fly anyway?
        * synp: So the cost of #3 is an extra line in any specification of a new algorithm.  Can live with that.
    
(At x1:52)
- Planning EDHOC Interop (Francesca Palombini, 15 mins)
    * test vectors at: https://github.com/lake-wg/edhoc/blob/master/test-vectors/vectors.txt
    * looking at an event in December

- AOB
    * Goran to lead related work at IETF109: CORE (Mon), CORE (Tue), ACE (Wed)
    * https://datatracker.ietf.org/meeting/109/materials/slides-109-lake-lake-related-work-at-ietf-109-00
    * NEXT STEPS?
        * before or after the "Seasonal Holiday"
        * agreement on having the virtual interim mid-December

- meeting ends