* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lake Status Pages

Lightweight Authenticated Key Exchange (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2019-Oct-19 —  

IETF-109 lake minutes

Session 2020-11-16 1200-1400: Room 6 - lake chatroom


minutes-109-lake-00 minutes

          # 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:
          - 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
          - 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
                  * 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
                  * 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
                  * 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:
              * looking at an event in December
          - AOB
              * Goran to lead related work at IETF109: CORE (Mon), CORE (Tue),
              ACE (Wed)
              * NEXT STEPS?
                  * before or after the "Seasonal Holiday"
                  * agreement on having the virtual interim mid-December
          - meeting ends

Generated from PyHt script /wg/lake/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -