Lightweight Authenticated Key Exchange (LAKE) - Virtual Interim in September 2024

Time

• 17 September 2024 -- 13:00-14:00 UTC

Chairs

• Mališa Vučinić
• Stephen Farrell

Notetakers

• Marco Tiloca
• Christian Amsüss

Action items recorded with "→" note

Useful Links

• Charter
• Mailing list
• Instant Messaging
• Minutes
• Remote participation

Agenda

• Administrivia (chairs, 5 mins)
• Presentation on PAKEs (Scott Fluhrer, 15 mins)
• Do we need a PAKE for EDHOC? (open discussion, 15 mins)
• Prelminary evaluation results of draft-lopez-lake-edhoc-psk-01 (Elsa
  Lopez Perez, 15 mins)
• Nextsteps and IETF 121 planning (chairs, 10 mins)
• GREASE
• AOB

Minutes

Administrivia (chairs, 5 mins)

• MV doing introductions; agenda.
• CA: Time allowing, before AOB, I'd like to ask on any possible
  future for the "grease" document in this WG.
• MV: Added.

Presentation on PAKEs (Scott Fluhrer, 15 mins)

• Scott F: presenting "The Joy of PAKEs"
• ScF(p2): LAKE discusses PSK for session resumption and possibly
  preshared authentication. PAKE offers better security for initial
  authentication; providing this for informed decision.
• ScF: Thanks to ECDH, it is not possible to derive the PSK for an
  attacker.
• ScF (p5): Possible weakness leveraging a dictionary offline after an
  active attack.
• ScF (p5): MAC_2 is important; it knows all that goes in apart from
  the PSK.
• ScF (p6): The attack is infeasible and a non-issue if one uses a
  very strong password or in case of session resumption.
• ScF (p7): PAKE binds key exchange and password; active attack needs
  to try online.

• ScF (p8): Trade-offs and limits (code/design complexity, no
  anonimity because responder needs to know which PSK is used, ...).
  Worth it? Discussion.

• ScF (p9): Two options from CFRG, assume CPACE would be right for
  EDHOC.

• ScF (p10): simplified explaination of CPACE.
• ScF (p11): Possible early mapping of CPACE into EDHOC. Changes are
  relatively minor, but they build on "exotic cryptography".
• ScF (p12-13): OPAQUE is asymmetric, as only one side knows the
  password. Shown high-level example. This might not be aligned with
  what LAKE was considering for the PSK-based key agreement.
• PW: If you use a 32 bit random value for PSKs, that's stronger
  right?
• ScF: In that case, there's no need for a PAKE.
• PW: So PAKE is better if there's a human involved.
• ScF: Right, humans are bad in choosing passwords
• PW: So it depends on the use case.
• ScF: Right, up to the WG to decide.

Do we need a PAKE for EDHOC? (open discussion, 15 mins)

(smoothly sliding into this from Q&A)

• JPM: My use case about PSK was resumption and external
  machine-generated (strong) PSKs. If any human is involved, PSK is
  not good, but if someone wants to do password in EDHOC, consider
  adding a different EDHOC method. Having in mind that no humans were
  though of as involved here, PAKE does not look like a good
  replacement for the PSK-based authentication as we thought of it.
• CA on chat: +1 on JPM "if someone needs it, it's a different method"
• GS: Not seen use case for this yet. What I've seen, both sides are
  devices without a human interface. So I'd favor the approach with a
  (pseudo-)random PSK as originally imagined.
• RML (on chat): +1 Agree with Göran
• RML: For me, EDHOC PSK was always high-entropy key. Never imagined
  password usecase. Comparing to TLS 1.3, they say there is
  considerations item of sufficient entropy on OOB key. Something like
  that would be enough.
• CA: We shouldn't just say that the PSK has to be high-entropy. We
  can point to this material from Scott: if one wants to use
  passowrds, it needs another method that is not defined here, e.g.,
  based on PAKE.
• SF: Do we have use cases that are anywhere in between, maybe codes
  printed at the back of things and have to be typed?
• MV: Not hearing comments on that, so people pleast think of it.
• CA (chat): A QR code can carry a full key. Only typing it may be
  limited.
• SF: (nobody in the room confesses to printing 4-digit numbers at the
  back of their products)
• MV, summarizing: Group agrees on proceeding with PSK where
  clarification on high-entropy key is in there (as is the assumption
  right now). If there is further interest, WG should explore more if
  someone brings a use case; that can be standardized in the future.
• (CA, RML, GS agree on chat)
• PW: If most of these devices are limited in connections per time,
  would it be possible that PAKE is always strong enough, so no
  disadvantage to PAKE compared to true random PSK?
• CA: EDHOC easily supports multiple connections per devices; can be
  done between a powerful "millions of connections" peer and a "2-3
  connections" peer.
• JPM: It's questionable that PAKE is always better. You also lose
  identity protection, and you need "exotic cryptography", which is a
  risk for implementation errors and harder to trust.
• SF (on chat): pointing to costs in Scott's slides.
• PW (on chat): ohh that is fair

(Chairs and all thanked Scott for the nice short, but very useful, PAKE
pressie!)

Preliminary evaluation results of draft-lopez-lake-edhoc-psk-01 (Elsa Lopez Perez, 15 mins)

• ELP (p2): Presenting current status of proposals and implementations
• ELP (p3): Two variants, depending on where the identifier of the PSK
  is placed in the EDHOC messages.
• ELP (p4): Ongoing implementation in Rust towards an experimental
  performance evaluation
• ELP (p5-7): Results comparing the two variants, considering message
  size, number of operations, and memory consumption. Flash and RAM
  results are not very sure yet.
• ELP (p8): Comparison of security and privacy properties for the two
  different variants.
• ScF: Forgot to mention during my presentation that variant 2 seems
  to be stronger against dictionary attacks b/c in variant 1 it's easy
  to mimick the client, but in variant 2 it'd need to impersonate the
  responder; it'd give a little more protection if someone ignored the
  advice and used human-level passwords.
• RML: About slide 5 with the results on the message size. In variant
  1, 3 messages give mutual authentication and implicit key
  confirmation. Variant 2 needs a 4th message for strong
  authentication.
• ELP: You're right.
• JPM: Impressive amount of simulations. Good to see that Variant 2
  performs better.
• JPM: Bytes and performance might be a bit preliminary; in EDHOC we
  had later changes to those properties. Might be less here. I think
  that identity protection is very important. Assume we're aiming for
  formal verification where something could pop up?
• Chat: CA likes variant 2, GS +1 on variant 2
• SF: Would you like to select 1 of the 2 and continue working, or
  keep working on both?
• ELP: It'd be better to choose and focus.
• SF: At what point would you like this decision? Eg. after adoption?
• JPM: Not sure when to choose; formal verification for academic
  researchers will be more interesting after WGA. Close to WGA, don't
  need for formal verificaton.
• Chat: CA +1 on WGA.
• SF: People definitely interested in this. Not sure when best point
  for WGA call is, but it's not far away.
• MV: IETF121 in November. Seems to be the case that WG is preferring
  variant 2. On formal verification, this will need to happen, but
  should not condition adoption on it.

Next steps and IETF 121 planning (chairs, 10 mins)

• MV: Expect a lot of participation. Do we want to request 1h or 1h30?
  Lots of things on agenda.
• GS: I've asked people from Uppsala University to cover fuzz testing
  of EDHOC implementations. At least 1 more draft upcoming.
• MV: Sounds like 90min. Any objection?
  (crickets)
• → request meeting by end of week.

Grease

https://datatracker.ietf.org/doc/draft-amsuess-lake-edhoc-grease/

• CA: This is about registering extensions that don't do anything
  other than ensuring the EDHOC executions don't break. Same spirit of
  TLS Grease.
• CA: The document looks done to me as an individual submission. What
  does the WG think? Good to happen here? Should I instead consider
  the ISE?
• MV: This is in the Charter, it makes sense to have it here. Next
  step would be WG adoption, since you presented.
• MV: Propose to update for Dublin, decide WGA there.
• CA: Works for me.
• chat: +1 from JPM, GS, MT who reviewed.
• SF: Will be interested in how many people have read the drafts.

AOB

• GS: There is work in the IEEE considering EDHOC. If you are
  interested, reach out and we can have some more discussion.