Minutes IETF126: lake: Mon 14:30
minutes-126-lake-202607201430-00

Meeting Minutes Lightweight Authenticated Key Exchange (lake) WG
Date and time 2026-07-20 14:30
Title Minutes IETF126: lake: Mon 14:30
State Active
Other versions markdown
Last updated 2026-07-21

minutes-126-lake-202607201430-00

Lightweight Authenticated Key Exchange (LAKE) - IETF 126

Time

  • 20 July 2026 -- 16:30-18:30 CEST

Chairs

  • Mališa Vučinić
  • Renzo Navas

Notetakers

  • Marco Tiloca
  • Christian Amsüss
  • Muhammad Usama Sardar (assist)

Agenda

Minutes

  • Administrivia
    -- chairs, 5 mins

MV and RN doing introductions

  • Renaming discussion: EDHOC -> LAKE
    -- chairs, 10 mins

Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-00-chairs-slides-04

MV: "EDHOC" has become a misnomer (due to DH for Diffie-Hellman and the
ongoing transition to post-quantum). Many are just using "LAKE". Ongoing
discussion.
MV (p8) presenting options. Opinions?

GS: We should do something. 2 is good. 3 is fine too. Any of those is
good.
TK: We have 802.15.9A that uses "EDHOC", was annoying b/c they want to
spell out every acronym completely, recursively. LAKE would be better,
b/c not acronym? OK, it is … still easier.
JPM: Do this; start using LAKE. Deprecate expansion of EDHOC, mention it
used to be called EDHOC. Option 4 seems too much. Could still update
IANA registries.
MV: So JPM, you propose 2+3?
MV: My proposal is clarifying sentence in ongoing documents (3), using
them ("LAKE" and non-expanded "EDHOC") interchangably.

MV starting show-of-hands.

  • "Do you agree on proceeding with both Option 2 and option 3, as
    shown on the slide?"

    • Yes: 31
    • No: 0
    • No opinion: 3
      MV: Let's proceed with this. Asking all document editors to
      enact that.

  • draft-ietf-lake-authz-08
    -- Geovane Fedrecheski, 5 mins

GF presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-lightweight-authorization-using-edhoc-00

GF (p2): Hackathon meeting outcomes. The whole ELA can remain a LAKE
item, in spite of conceptual similarities with ACE. The Voucher_Respone
becomes a CBOR map. Confirmed to keep different ephemeral keys for EDHOC
and the ELA components (also good to keep it aligned with upcoming EDHOC
authentication methods based on KEMs)
GF (p3): Questioned many things, arrived at many things staying the
same; indicates maturity.
MV: Any opinions on WGLC readiness?
(some thumbs up)
MV: Chairs will proceed with WGLC.

MT presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-20260720-lake-draft-ietf-lake-edhoc-impl-cons-00

MT (p2): New topic resulted from resolving WGLC comments.
MT (p4): "How long should successfully completed sessions be retained?"

MT (p6): This document may be updated when other methods are added.

JPM: "Aborting the session is never wrong" … can be DoS session.
MT: This is about when it is completed.
JPM: OK

MT (p8): Can rename to LAKE happen as part of shepherd review?

MV: Looking for shepherd, proceed then. AD, expect a surge of drafts!

Marco presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-20260720-lake-draft-ietf-lake-app-profiles-01

MT presenting.
MT (p3): Thanks for reviews, all answered individually.
MT (p5, p12): app_prof clarity often commented on; applied Yuxuan's
resolution.
MT (p7): CDDL enhancements
MT (p9): Consistency on expanding editorial issue led to improved error
handling.
MT (p14): IANA reviewed submitted documents; will go with TBD1/TBD2.
Update now or with LAKE rebranding?
MT (p14): Normative reference … in practice this stops the document
before IESG before those are sent? (MV: Can be after shepherd review)
MV: Follow process, proceed document independently; in RFC queue it will
wait. Seems like it's similar timeline, will just create a cluster.

Christian presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-04-grease-00

CA (p2): Motivation recap.
CA (p3): Ack reviewers, WGLC completed.
CA (p4): On fail, is it fine to use "SHOULD NOT" for retrying? It should
be fine here, even if different from common practices in the web (and
-iab-protocol-greasin is no strict either).
CA (p6): -iab- document points may or may not be acted on when feedback
comes.

CA: I think it's ready for the Shepherd write-up. Happy to take more
comments.

Yuxuan presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-remote-attestation-over-edhoc-00

YS (p2): Two updates, -05 and -06. Simplified by removing a dimension
that was not used.
YS (p3): Showing examples, also including the attestation binder.
YS (p4): We use a different attestation binder depending on doing intra-
or post-handshake attestation.
YS (p5): Editorial clarifications thanks to reviews.
YS (p6): Structural changes coming up after removing redundant text.

MUS: Raised issues in several last meetings that are still unaddressed:
Who is benefiting from this work? Who is using it in the industry? Can
you share links to their implementations? Had conflict between your and
our results of formal analysis. CVE-2026-33697
(https://www.cve.org/CVERecord?id=CVE-2026-33697) for attested TLS
exists. Our code on attested TLS
(https://github.com/muhammad-usama-sardar/intra-handshake.fail) and
paper on attested TLS
(https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS)
is out there. Similar attack also applies here.
MUS: It's not a one-time thing. Just status at one point in time.
Clearly insufficient.
MUS: What is the value in doing intra-handshake attestation? Evidence is
not applicable a minute after. You have to do post-handshake anyway. Why
add unnecessary complexity of intra-handshake attestation?

MV: These are several orthogonal points; short on time.

GS: One user of EDHOC is AssaAbloy for smart locks. They run the
handshake at every lock/unlock operation.
MUS: Did they ask for intra-handshake?
GS: Topic of discussion; proposing both. But you asked for application
-- and here it happens at usage time.

MUS: Give us a concrete implementation, and we'll give you a concrete
attack.

MV: Had interim 2m ago, designated an independent evaluator to examine
formal work on this and your work. Reviewer asked for artifacts -- are
they available now?
MUS: Forget about formal. Author claims one open-source implementation
is available; please share the link and we'll provide concrete attack.
MV: Believe we can provide that.

Elsa presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-06-edhoc-with-pre-shared-key-authenticaation-draft-ietf-lake-edhoc-psk-07-slides-126-lake-edhoc-with-pre-shared-key-authenticaat-00

ELP (p2): -08 addressing WGLC and hackathon comments.
ELP (p3): Advantanges and disadvantages to associating a PSK with a hash
function or a whole cipher suite. Advantage of cipher-suite-associated
is it can be shorter. For -08, going with hash function association.
ELP (p4-p5): Erik's review – addressed as on p5.
ELP (p6): More updates from the WGLC review: pointing to
-lake-app-profiles for optionally indicating support for PSK resumption;
more precise statements; PSK associated with hash; confirmed that 2
bytes is a good default size for PSK identifiers. Clarifications about
using the EDHOC + OSCORE combined request (RFC 9668).
ELP (p8): on post-compromise integrity – now stated with conditions.
ELP (p10): from hackathon – identity hints in message_2? Following TLS
1.2. There's two possible ways: one based on a new field in the
plaintext of message_2, and one on a new EAD item for EAD_2. Using an
EAD item is preferred for different reason.
ELP (p11): Will publish next version

RML (on chat): I prefer id hint EAD_2

Jonathan Hoyland (p11): I wonder if there is an issue where by changing
the hint you could change which key was selected? If you pick identity
from hint, could I change which key is used through the hint?
ELP: When provisioned, key already has information about with whom to
use it. Can be used to simplify selection. Avoids responder having to
check with different PSKs – but should already be provisioned.
JH: So no different people using the same hint in different places? If
it's a hint, it can collide. Could wind up with confusion attacks.

JPM: As with TLS 1.2 – not seen any attack on TLS1.2. But benefit of
using EAD is that more discussion/improvements can happen in a different
draft. In principle, yes, there is room for confusion due to colliding
hints.
JH (on chat): So to expand on this a bit, I remember an attack on
draft-14 of the TLS 1.3 draft where an attacker could make a client
associate keyid_A with key_1 and the server associate keyid_A with
key_2 and get them into a weird state where they both completed a
handshake using keyid_A but they didn't agree on the security state. I
can't exactly remember the details but the issue was that there wasn't a
binding from the key_id to the key, and the key hint seems like a
similar shaped thing.
JPM (on chat): Jonathan, thanks for the additional details. You
mentioned something similar during an earlier meeting. Then I did not
understand exactly what you meant but your comment made me read TLS 1.3
again and realise we needed to bind the external PSK to a specific hash
function. I will try to see if I can find any info on the attack and how
it was fixed.
JH (on chat): I found the paper I was thinking of. It's section 5.1 of
Cremers, Cas, et al. "Automated analysis and verification of TLS 1.3:
0-RTT, resumption and delayed authentication." 2016 IEEE Symposium on
Security and Privacy (SP). IEEE, 2016. And it was version 10 not version
14.

  • EDHOC-PSK with Ephemeral KEM: a formal verification using SAPIC+
    -- Clément Papon, 10 mins

Clément presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-edhoc-psk-with-ephemeral-kem-a-formal-verification-using-sapic-00

CP (p2): Overview. Based on formal analysis of EDHOC-PSK.
CP (p6): Flow
CP (p8): Assumptions in the symbolic model
CP (p9-p10): Proved properties: mutual authentication, key agreement,
confidentiality, resistance to unknown-key-share attacks
CP (p11): Result is same as was obtained for EDHOC-PSK.

MUS: On p8. Why do you take these as assumptions? If PSK or KEM secrets
leak, you have a problem. Isn't that conflicting "minimal compromise
scenario" as mentioned? What is motivation for extending protocol
analysis with these assumptions?
CP: If you only leak PSK, you may not obtain everything. Sometimes you
need more than the PSK, you need leak of two secret elements.
MUS: But if you leak the KEM secret key, don't you loose security?
MUS (p11): What new insight is there from this work from formal or
designer perspective?
CP: Main point is to obtain PQ security.
MV: Was answered: properties are preserved in PQ model.

VS: On p8, what is the difference between the classic or SAPIC+ model
for xor encryption?
CP: (...) randomness independently from shared secret. Randomness plays
role of secret key for responder.

  • PQ-EDHOC Design Team summary
    -- Renzo Navas, 15 mins

Renzo presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-08-pq-edhoc-dt-summary-ietf126presentation-00

RN (p2): Joint work of the design team. Will be fast, for more talk see
interim recordings.
RN (p3): Recap on modus operandi of the design team meeting.
RN (p4): The 4 objectives; focus on objective 1.
RN (p5): Categorization of constraints to better understand feasibilty
and performance of PQ-EDHOC
RN (p6-7): Building on the categorization, evalution of performance for
different PQ setups (e.g., with different combinations of signature and
kem, or with PSK)
RN (-p10): Outcomes and who-can-do-what; can work in C1.
RN (p11): Classified qualtiatively different scenarios. Two frontiers:
on memory constraints (red), CPU-vs-bandwidth (violet).
RN (p12): We recommend the new PQ ciphersuites for method 0 (sig-sig)
and the new method 4. These are WG documents.
RN (p13): We recommend a KEM-KEM authentication method. This is also a
WG document now.

RN (p17): state summary. (And anything to CFRG will take years to bring
usable results).

MV: Thanks to the design team and to Renzo for leading it!

Lidia presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-8-kem-based-authentication-for-edhoc-00

LPF (p2): What it is – signature-free PQ scheme.
LPF (p3): Reusing structure. But in DH mix public and private directly.
KEM does not: Combine secrets, and then send and receive usable secret.
Thus extra messages.
LPF (p4): M4 and M5 encrypted with same secret key K4 from PRK.
LPF (p5): in green, differences from original EDHOC.
LPF (p6): Recap of properties, preserving what is in the original EDHOC.
Each new secret goes into state. Again, initiator identity protection
against active attackers.
LPF (p7): We have to align the IANA considerations to be consistent and
not overlapping/redundant with those of -lake-pqquites
LPF (p8): Mode with unidirectional authentication can reduce number of
messages – but need to see WG interest and concrete use cases (as it
weakens security properties).
LPF (p4): On messages 4 and 5. Use of same key is correct? But also: Is
message 5 necessary? New work to check: Is this mandatory, or can this
be optional as in classical EDHOC?
MT (on chat): The use of message_5 can be phrased in the same way that
the use of message_4 is phrased in -edhoc-psk. A fifth message is
needed, and that can be EDHOC message_5, unless it is possible to have
as fifth message a message protected with the established application
keys (e.g., with OSCORE)

MV: Please review!

  • Formal verification of EDHOC with KEM-based Authentication
    -- Vaishnavi Sundararajan, 10 mins

Vaishnavi presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-09-formal-verification-of-edhoc-with-kem-based-authentication-01

VS (p4): Claimed properties to prove
VS (p5): Assumptions, models, etc. used for the formal verification
VS (p6): Different options for specifying KEM functions.
VS (p7): WIP, but so far verified some properties.
VS (p8): Summary of results. The first two options have been covered for
all the shown proved properties. Using the third option is work in
progress.
VS (p9):

MV: Code available?
VS: Soon (cleaning up)

MUS: Same question. p8. Same results as other approaches. Did you learn
something useful by using different models? Or do they represent the
same?
VS: Useful conclusion is that we don't lose anything by using KEMs.
Other conclusion is that there might be other properties of interest in
PQ model that we haven't looked at.
MUS: Between columns 1 and 2, any insights from 2 over 1?
VS: 2 is faster :-)
VS: Results are not different, but we dont't leak any of the randomness
yet. Might be leaking more parameters, but not right now.
TW: MUS, read Cremers, Dax, and Medinger who describe exactly how the
binding properties work and extensively discuss the differences between
approaches [1] and [2]. (I was author of the KEMTLS analysis in
[1]).
JH (on chat): The [published version of the] paper is here:
https://dl.acm.org/doi/abs/10.1145/3658644.3670283 It's a really good
read. Strong recommend.
TW (on chat): the eprint version of that paper is more up to date.
Great paper.
VS: That could allow us to construct a property that is KEM specific. So
far, only looked at what we imported. But have subtle ones we should be
looking at.
TW: More in summary: TLS key schedule hashes in all public keys, so you
should get all public keys -- should be the same in EDHOC because of
transcript hashes. Don't expect different results, but good you do it.
VS: Might look also at using weaker hash schemes.
TW: More of an academic excursion, but could be fun!

Lidia presenting. Slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-lake-10-kemsignature-based-methods-00

LPF (p2): Motivation building on performance/benchmark observations
LPF (p3): Thinking of new EDHOC methods where one party authenticates
with a KEM and the other one with a signature
LPF (p4): That's useful in pairs where the abilities/resources of the
two peers are not evenly distributed
LPF (p5): Little modification; just following method 3 to other methods.

MV: Who read it?
(a few hands)
MV: Relevant to LAKE?
Quynh Dang: Sure!
GS: As for unilateral authentication; this is more important than
unilateral, especially using the asymmetric properties. (Need both
SIG-KEM and KEM-SIG). Both or none, but something to work on, Not top
priority, but do it.
MV: Will need more opinions before adoption call; go to list.

  • AOB

(none)