**Session Date/Time:** 20 Jul 2026 14:30

[00:00:07] **Göran Selander**: Yeah. Let's get started.

[00:00:20] **Malisa Vucinic**: Everyone. This is the lake working group meeting. My name is Malisa, and this is my co chair, Renzo Navas. Renzo is still recovering from last night.

[00:00:32] **Renzo Navas**: I'm from I'm from Argentina. Yes.

[00:00:35] **Lydia**: Yes.

[00:00:37] **Renzo Navas**: Congratulations, Ben.

[00:00:39] **Malisa Vucinic**: So this is an ITF meeting, so the Note Well applies. The Note Well governs several policies that you agreed to when participating in an ITF meeting. These policies refer to intellectual property rights, privacy and conduct. Please read the note well by scanning the QR code. So this session is being recorded and the presence is logged. Please make sure to sign into the session by scanning the QR code that is available in front of the door. We use Meetecho for hybrid participation of on-site and remote. Please keep video for remote participants, please keep audio and video off if not you if not actively talking. So here, you can find some resources for this ITF. And I would just like to start by giving a brief status update of the working group. So since ITF-one hundred twenty five, we have had two Internet drafts adopted following the work of the design team that I would like to thank, at this opportunity. So these two drafts are draft-ietf-lake-, PQ suites, which defines how the protocol how the lake protocol operates in post quantum setting and specifies quantum resistant Cypher suites, and the draft- itf- lake called which specifies the authentication method. Four Internet drafts are post working group last call. All four will be discussed today. Two drafts are nearing working group last call. These are the drafts on authorization, third party authorization and on remote attestation. We'll be hearing updates on these today as well. And as in the previous meetings, we will be we are continuing our efforts on formal verification on all the specifications that we produce in the working group. We will be hearing two presentations today. So I would like to take this opportunity to thank Vaishnavi and Clement, who kindly will present their formal verification efforts during the meeting today. So this is the agenda for today. We have maybe five minutes of flex time. It's quite packed agenda, but nevertheless, does anyone want to bash this agenda? I hear no objection to this agenda, so let's continue as proposed. The first item on the agenda is a renaming discussion. So to give you some context, the name of the protocol as specified in RFC-ninety five-twenty eight is Ephemeral Diffie Hellmann over COSE. So with the working group going quantum resistant, EDHOC expansion, specifically Diffie Hellman has become a misnomer. And we have observed that the people outside of the working group have increasingly been referring to the protocol as the lake protocol or lake- slash EDHOC, as you can see in some of the references that I was able to find. This is not the first time we're having this discussion. In August 2022, we had a mailing list discussion where we discussed this. And the chair set the time, decided that there was no consensus to rename the protocol to Lake. So we stuck we continued using the name EDHOC. We are bringing this for discussion now that the group is going quantum resistant and EDHOC has apparently become a misnomer. So I would like to poll the working group for different opinions. I have listed here a couple of options that I believe are relevant on what we can do with respect to the name EDHOC. The first option is obviously to do nothing. Second option is to deprecate the EDHOC expansion but to keep using the acronym EDHOC. Third option that we that I have come up with is to start using LAKE to refer to the protocol specified in RFC-ninety five-twenty eight with a clarifying sentence in the terminology section. And the fourth option that is full steam ahead is essentially to publish RFC ninety five twenty eight bis updating all names, including all the other registries to Lake. With that said, this is I'm opening the floor for discussion, and I would like to hear the opinion of the working group on this particular topic. We have eight minutes to go to discuss this issue. Are there any opinions in the room?

[00:05:55] **Göran Selander**: Okay. Yeah. Think we should do something. And option two is good. I think we we we could just stick to a name. That's fine. Option three is fine too. Lake slash EDHOC terminology section. Any of those, I think, is good.

[00:06:26] **Malisa Vucinic**: Okay. Thank you, Göran. So we have.

[00:06:30] **Taro**: Taro, So we actually have an IEEE1549 59 a that was published a couple of months back that actually uses EDHOC. And it was really annoying because they actually want to spell out every acronym completely. And Edhoc is quite a long acronym, especially when you expand COSE and and all of the things that are there. So so and when they were to have a project name

[00:06:56] **Malisa Vucinic**: with that, the project name we

[00:06:57] **Taro**: have to then we discuss these additional key management. We need to mention it. They could be actually better at that case, I guess, because I don't think it's an algorithm with is actually accurate with that.

[00:07:09] **Christian Amsüss**: Yeah.

[00:07:09] **Jonathan**: It's I

[00:07:09] **Taro**: would like to think. Yeah. Okay. That would be much easier.

[00:07:13] **Göran Selander**: Okay. Okay. Thank you.

[00:07:19] **John Preuß Mattsson**: Yes. John, I think we should do this. I think we should start using Lake. I think we should deprecate the expansion of EDHOC. We probably still have to mention that it used to be called EDHOC. I publishing this version of the RFC seems maybe too much. But when we start calling it late, maybe we should update the IANA registries. That's not so much work. Yeah.

[00:07:54] **Malisa Vucinic**: Okay. So if I understand correctly, you you would like deprecate EDHOC expansion. So options two and three as they're proposed on this slide. So we I put here a possible resolution that we could have a clarifying sentence in ongoing documents in the in the group that we use lake to refer to the protocol specified in RFC ninety five twenty eight and that we interchangeably use lake and EDHOC as the name of the protocol. So are there any other comments? I don't see any people in the queue. No? Okay. I would like to start a show of hands to see who would approve this resolution. So essentially, adopting both option two and option three as shown on this slide. So give me a minute to turn. So I started the show of hands. So please use the on-site tool or your Meetecho client to vote. So there are no votes against so far. There is a clear majority of 30 vote 31 votes, yes, and three no opinion. So that is as good consensus as we can get in the group, I believe. So let's let's proceed. So with that, I would ask the document editors to, start referring to the protocol as the lake protocol in the adding a clarifying sentence in the terminology section of their corresponding drafts. And we will discuss all the other possible resolutions on deprecating the EDHOC expansion as given in on option two. Okay. I will terminate the show of hands. So with that, I guess we can start with the the agenda. So the first item on the agenda is the LAKE authz draft, and the presenter is Giovanni Fedrzeski. Slide clicker.

[00:11:15] **Renzo Navas**: Hello.

[00:11:21] **Giovanni Fedrzeski**: Hello. Thank you, and hello, everyone. My name is Giovanni, and I'm presenting lightweight authorization using EDHOC. Here's the status of the draft. We had the version zero eight released with, editorial fixes, and we have some updates on the hackathon this weekend. So we had one side meeting where we discussed a proposal by Christian, where with the new flow of, sending the voucher request and response on message three and message four. Should we keep Ella in lake or move it to ace? Because the flows kind of remem reminds of the flows in ace. And after discussing with several coauthors and other people involved in, we decided to keep it in lake. And one of the limitations is that we this solution would involve returning a credential, which would not work on message four. Then we found a bug on the CDDL in Voucher Response during this discussion because it returns an array where both items are optional. And then when you have only one item, it's hard to know which item are you having because both are of the same type. So we're turning that into a map. That's a simple fix. Gabriel asked the question about returning authorization information, something that is more detailed from w to v, because we can give more w can give more detailed information to you, but not to v. But now that we are turning voucher response into a map, that can be easily added because it can be just a new registration of a field for that map. So, actually, everything kind of falls in a nice way. And then we had another discussion about whether we should keep using separate ephemeral keys in Ella and in EDHOC. And the point being that if we go back to using same ephemeral key as used in EDHOC, we save, for example, 32 bytes on the wire. But then turns out that the CAM use case where we have a cipher CAM cipher text being sent from u to v already needs a few there. So if we also send extra ephemeral key between u and v, we have a more homogeneous design. So that's a reason enough to keep the field like that so it simplifies implementation. So all in all, it means that all this discussion, we're kind of re questioning some assumptions

[00:14:09] **Clement**: of

[00:14:09] **Giovanni Fedrzeski**: the protocol. And finally, we arrive that we don't change anything, which is a good sign that the draft is stable. And, so in my opinion, it's ready for working group last call. Thank you.

[00:14:24] **Malisa Vucinic**: Thank you, Giovanni. Do we have any opinions on the readiness of this draft for working group last call? So I see thumbs up. Yes. Okay. So the chairs will proceed with the working group last call of, authz as as proposed by Giovanni, and then we'll have an opportunity to review the draft and discuss its discuss its future.

[00:14:58] **Göran Selander**: Thank you. Thank you, Giovanni.

[00:15:03] **Malisa Vucinic**: So the next item on the agenda is Marco implementation considerations draft. Mark this draft is in working post working group last call. So Mark will present the updates to the draft following the working group last call comments. Mark, you have ten minutes, I believe, and I will pass the slide control to the slide clicker. No. Oops. Sorry.

[00:15:39] **Renzo Navas**: Two.

[00:15:45] **Malisa Vucinic**: There you go.

[00:15:46] **Marco Tiloca**: Thank you. Hi, all. This is Marco. This first half I'm going to present is about implementation considerations for Lake. Yeah. The overall scope is unchanged. It's about giving considerations for implementers that were intentionally kept out from the original specification to not, yeah, make the protocol description too heavy and and to leave them for a separate document. In this one, we are still covering the same number of topics plus new one that I've added as a resolution of working request call comments. But it's mostly about what to do when EDHOC sessions become invalid or material related to those becoming valid. And as a new one, what to do and until when for existing completed EDHOC sessions coming from comments during working with Pascal, the different trust policies for learning on the fly, until then unknown authentication credentials, and the site processing of incoming ed edoc messages when it comes to authentication credentials and EID items. And finally, guidelines inherited from an old core document about using edoc over co op with blockwise. And other than edoc in general, this considers some specific case cases in point like the edoc and those core profile of ACE and and Ella. Okay. The main thing really here was addressing the working of possible comments. The call run-in May. There were four reviews coming on the list, and thank you very much to the reviewers, Brian, and this new version seven submitted as latest, hopefully addresses all the points raised. And I sent individual replies also on the mailing list to the reviewers. So starting with Brian, he had one comment, and, essentially, well, he noted that there was a whole section about what to do with sessions that become invalid for for whatever reason. He was also hungry about information on on what to do with sessions that are successfully completed and for how long they should be retained and why. And, well, he essentially gave the answer in his comments. But taking that from there, I added this as an additional topic of clarification in the introduction already in the list of topics covered. Then I added a new section three retention of completed the doc sessions that started in session three zero addressing Brian's comment and then continue as a follow-up, in fact, to address a comment from Rickards review. But, essentially, sessions completely are supposed to be kept until something bad happens, like, they become invalid or the the peer runs out of memory, whatever. And a possible useful thing is to run a DOC update, for example, or DOC export there for reasons that do not apply right when the session is is completed, but only later. Review was mainly about to comment stating clearly in two different parts, I think, then well, the EID field a single EID field in the message can, in fact, contain multiple EID items that KEMe up in in different situations. And we know it come up also in in the remote attestation draft. So it it's a pretty clear now in two or three, points in the draft. And the most difficult comment to address of all, believe me, having a a single compact table summarizes the meaning and the advantages of the different trust policies and what they means is now added in the section discussing that topic together with some short and introductory text. As as review, was one comment about mentioning that, yeah, as intended, this document focuses and discusses thinking, assuming we use the other methods originally defined in 9528, and it's up to future documents that may update this one to expand with considerations that apply when instead other methods are used still based on asymmetric authentication credentials or instead on pressure keys, for example. Request review was, one comment that, got also inspired by a a report, we got from implementers that noted, well, a strange behavior that was initially filed as a bug. It happened not to be a bug, just legitimate behavior, but we realized, well, it it'd be good to give considerations for implementers about that. Essentially, it's an even a look session is complete. Ad hoc gives a lot of latitude about what to do if the peer receives an error message. There is a may in the RFC. So any reaction is fine in principle. It may just ignore the error message or or terminate the session and lose the application key material derived from it. So there there's nothing wrong according to the RFC. But in practice, there are situations or point in times after which it doesn't make sense to drop the session altogether if an error message is received because beyond that point, any error message cannot be legitimately be produced by the other peer. It must be something spurious or or later or injected. So I tried to discuss this in general and to give a complete a concrete example step by step in a particular and typical case where EDHOC is used over co op for all score in the forward message flow. And once the responder has successfully processed message three, from then on, if it ever receives an error message that matches by identifier with the session, it can safely be ignored, essentially, as long as according to the application profile message for is not used. And then it's up to the implementation to practically handle in a particular way the ignorance or the skipping of the of the processing of the error message, I suggested possible strategies, one of which I I adopted in in the California implementation to handle this case. So that was a very useful input also from from those developers that is reflected now in the draft. John?

[00:22:14] **John Preuß Mattsson**: It says that aborting the session is never wrong. The reason for the may might be that error message is an attack on availability. So and so I I don't agree with this. It's never wrong and safest.

[00:22:32] **Marco Tiloca**: The session is completed. The session is completed. That that's the starting point. Yeah. Yeah. This was about the completed session. Thanks.

[00:22:40] **John Preuß Mattsson**: But to oh, okay. Why would you drop it then? Yeah. Okay. Alright. Never mind. Okay.

[00:22:51] **Marco Tiloca**: Yeah. That's it. We think we addressed all the comments received during working request call. All the content should be here. There's nothing left open open module using Lake. That KEMe up today and, yeah, it has to be probably confirmed on the list, but still it's going to happen. Maybe that can happen as part of addressing the shipper's review as a final thing. Or I don't think we necessarily need a new version right now because of that, but for sure before shipping it.

[00:23:22] **Malisa Vucinic**: That's fine with me. So, yeah, we will be looking for a shepherd and proceeding then with shipping this draft so our ID can expect a surge of drafts coming from, in the the in brief future. Thank you, Marco. So the next item on the agenda is application profiles also led by Marco. Do you want to share it?

[00:24:06] **Renzo Navas**: Do you see number three? Wait.

[00:24:16] **Göran Selander**: Yes.

[00:24:22] **Malisa Vucinic**: Okay. K. Marco, you have fifteen minutes for this one. Let's start.

[00:24:28] **Marco Tiloca**: Thank you. I'll try to be quicker. Yeah. This is about coordinating the use of application profiles for a doc. Yeah. To recap, the the peers running and are gonna have to agree on a number of of parameters and settings that, in different ways can be expressed in terms of an application profile. Those can be expressed in turn into different, approaches. A la carte is a list of individual features or, as a set menu of features that you can identify by by integer value. And this coordination can or totally happens in in different places. Define a particular CBOR object as a CBOR map proposing the set menu identified by integer. You can use target attributes, in a link, or during a doc, in in a new EID item or, as the value of an error message of a new, error type. And also as the latest addition a few versions ago in the SBCB resource records. If you use DNS for discovering a server that can support a doc. And, yeah, like the previous document, this latest update was about addressing the comments received during working group plus call that happened right after the one for the previous document. There were five reviews from Yuxuan, Brian, Giovanni, Elsa, and Gabriel. Thank you very much for all the input. It was very useful. Same thing, latest version addresses this, and I sent individual replies on the mailing list. Yeah. Before starting with the main reviews, I just noted, of course, in the process some minor fixes to do, including in a CDL notation and in the AYANA considerations. I also noted a few more things to say or to be more precise on the encoding of a media type and suggested requested values for the code points. Yeah. In the following, if you see a lake doc, I mean, this document. If you see ace doc, I mean, the related ace document when one of the items is defined. Yes. Starting with review, this was a a recurring comment that other reviewers always made, and the resolution seemed to me was fine to address all the common sources. Was asking to clarify the the purpose of that parameter uprof that, in fact, can appear in two different object. Yeah. She suggested an interpretation that, of course, was correct. And building on that, I just clarified the exact opinion of that parameter more precisely, as soon as I could, in the introduction and then later on in the specific, sections that pertain to to different, objects where that parameter, is involved. You can add more comments to explain why it it can be useful to advertise support for application process specifically during the end of session in addition to the other mechanisms that are also defined in the draft. Yeah. I explained that also in section five when this topic is discussed. It's essentially a a low bar because the only pre requirement is really supporting that particular EID item or the corresponding, educator or code, which is a lower bar compared to, for example, having available a protocol that can rely on linking or or even DNS. And this enables also peer to advertise its capabilities if it is, a client only. And it enables a peer also to to make some more specific advertisement having in mind that particular EDHOC session, that is ongoing. Related to that, your channel also asked if if there's any any rule, any procedure to handle any any conflict between what is advertising, what happens. Yes. There is. It was always around. It's limited to infringing what the prescriptive parameter says. That was clarified. And in the ace document, we took advantage of that comment to also clarify there even better the meaning of prescriptive parameter where the concept is introduced. Brian had an an interesting comment about introducing in the terminology already how a document reader can use an expert expression to extract all the CDL snippets. Yeah. So under his own suggestion, I just started from his text in one of his document, and and that worked. And he also noticed something to to fix in a CDL definition. You cannot really have map as a right value there. And and in suggesting to fix that, he also suggested how to improve that notation to be more pluggable using the CDDL software that honestly had not very much experience with. At least I managed to produce something that that validates, and I'm building on that CDDL socket in this document already by extending it on the fly with additional parameters that are defined in the following sections. So, also, in in the future, if these items are further extended, it should be seamless to to keep this definition up by plugging more things. Another comment from Brian was about, yeah, going through the different defined and register well known application profiles, the first set proposing this document, and giving at least a short high level description of their gist, what they mean, in what situation it is. It it makes sense to map that that use of that application profile, and I went through them one by one. Giovanni had something that was, in fact, an editorial comment that that evolved into something more than editorial. He suggested for self containment to to expand what was error code, error code one into something longer where the the name of the error code was spelled out fine. I I started to do that. And beyond a specific suggestion on that error code, I started to do that for consistency on the other error codes until I started to do that on the newly introduced error code. And I noticed something weird. When sending an error message with a new error code, the idea was to advertise what the sender of the error message supports, which is fine. It's a bit weird that at the same time, that peer is not telling to the other peer what went wrong and and what error occurred. It's kind of a pity. So it was pretty simple. Fortunately, I extended the semantics of the value of that error code to be exactly what it used to be as an advertisement of the supported features, prepended by a text string exactly like you do with error code one as a description of the generic error, that occurred. So at least the the occurred error is also, communicated to the other peer. And because of that, essentially, that new error code, has now a new name is not supported at the application profiles anymore, but unspecified error and supported EDHOC application profiles. So if you want, it's an improved version of the old Aircode one. And Giovanni also had another common spanning between the operational considerations and the security considerations. We are already saying that in case a piece of information is advertised through unprotected communication, that's, at best a hint. But Giovanni also noticed that somewhere else, we were starting to discuss about persisting the learned information to not have to relearn it later on in the future. And as you noticed, well, that that's fine if you managed to confirm the hint as something reliable, which is now discussed with a concrete example that Giovanni self provided. So that was a very good point. As as review, same comment as that coming from clarifying the meaning of the parameter of professor in different places and the changes made, for applied here just as well. She also asked if one of the parameters for agreeing about the size of output of Edoque exporter was sort of implying that a PSK resumption was also supported. And the answer was no, and we were not advertising, that explicit ability. Now we are. So it was as simple as defining, a new parameter, boolean, non prescriptive PSK resumption. It's really analogous to another parameter of the same kind, to indicate support for the EDHOC plus score combined request. So it is defined in a section. There is an example, and there is the corresponding IA registration. So now you can tell explicitly if you support PSK resumption as a sub standing capability, which I wrongly assume was to be taken for granted if showing support for method four. But, no, it's something more. Finally, Gabriel, also comments aligned to those from about the the parameter, but also seen from another angle clarifying in the first place the difference between the two, objects involved, as soon as possible. So I did that, in the introduction already, in in the first paragraph where it made sense, to make that comparison. And then again in section two about the, the object defined in this document, stressing the difference between, that, and the other one. And finally, Gabriel also triggered the the need for a clarification. I think, he was a bit confused in seeing parameters related to web linking and and why not defining those for the object instead. Well, it's it's it's two different words. The object is one thing with these parameters. Maybe it wasn't clear, in the old text that the parameters it was he was referring to were really for for linking to be used, in links. So I expanded on that, when they appear in in introduction, clarifying also with references that that's about web linking. And, of course, those web linking parameters have corresponding parameters for the CBR object. And when it comes to web linking, we are, by the way, building on on something that was started already in RFC nine six six eight and and where we are contributing with a bit more interest. Yeah. As next steps, we received right before the beginning of the, I think, a review from Ayana that is pretty much editorial. They noted we were suggesting some values for some code points. One of those was taken very recently. I didn't notice close to the cutoff. So they're just suggesting to replace those with t b d one and t b d two. You can find it already in the on the GitHub. So I can push now a new version with a change, or I can wait and do that together with the lake rebranding later on. But, yeah, we have three normative references that are draft, and one is really done. I believe it it has at least enough position to pass with the ASG evaluation. But one is in the ASG working group. It's still ongoing work, though we hope to complete it relatively soon and to have a working group last call there. And the third one that was added in this revision following SSS comment is a doc PSK. So I I don't know how exactly to proceed here in in in having a new version, I think, with detail and when the share preview can happen, but I can imagine that then in practice, this stops before going to the ASG until those three normative references are also sent.

[00:36:24] **Malisa Vucinic**: So I propose we follow the process and proceed the document independently, and then you essentially, once it's in the RFC queue, it will it will wait for the other documents to be published before. Right? So we just progress the document independently. So and the the EDHOC PSK draft is in working with last call as well, which is in our hands kind of. So it seems like a similar timeline. So it will just create a cluster when publishing.

[00:36:56] **Marco Tiloca**: So is it finally addressed the AYANA fix also as part of the shipper review? Yes. For me. Okay. Then then that will wait too. Okay. Yeah. I'm done.

[00:37:06] **Göran Selander**: Okay. Thank you.

[00:37:07] **Malisa Vucinic**: Are there any comments for Marco on this draft? So in the absence of comments, we will proceed with we'll look for a shepherd and progress the draft outside of the working group.

[00:37:23] **Marco Tiloca**: Thank you.

[00:37:25] **Malisa Vucinic**: Thank you, Marco. The next yes.

[00:37:32] **Renzo Navas**: The next is Christian. You're gonna present Greece, head of Greece. It's Lake Greece now. Yes. Sorry.

[00:37:45] **Christian Amsüss**: You can you pass me slide control? Oh, okay. I'll take that too. K. Hello, everyone. My name is. I'm back with the topic of greasing lake now. I won't go into details on the background, just that there are extension points we have to use then to make sure that nothing that in implementations or middle boxes breaks it and and creates a situation where we can't use them anymore. Thanks to the reviewers. This has, I think, been past working group group last call. Marco and mailing already essentially confirmed that I addressed their review points. One that I'd like to point out of mailing is that, you know, what happens when someone sees the list of of grease EID items and creates a hard coded list of, yeah, or we let we let these through and the others will stop. Yeah. We can't stop that. But what we can do, and that is a general plan already outlined in the document, that over time, more EAD items can be added that have the very same semantics so that will help keep the degrees flowing. As for Julia Tully's comments, I've grouped them in two. So there, I've addressed some. But there are a few where I think that kind of briefly talking about them is prudent, grouped into some that are relevant to implementations and some that are editorial. The first and probably the most important is that in Greece for TLS, it says, look, nothing should automatically retry. And I think that's good guidance when it's about grazing something that will be apparent where a failure will be apparent in a web browser. I don't think that's good guidance for an IoT system that might not have any user interface at all and that might rely on the secure connections to get information about the failure out in the first place. So that is a deviation from from prior brief documents, and I think that's fine. Reporting that how that reporting should happen was also a big question. I have now added as brief reference that says that one way to do that would be using QuoteConf, but, I think it's important to point out that this reporting is to the operator. Whether or not the operator publishes that on a particular network, there is trouble when you grease your, traffic is out of scope for this document. Yes. This is something that kind of people should coordinate on, but privacy concerns say that we can't do that automatically. And on the quality of randomness that goes into deciding whether and how to grease, There is a point now that says we already have a cryptographically secure source of randomness. So, like, just to be sure, why not use that? On the editorial side, there was a bit of concern about how this interacts with other documents, but I think that's generally sorted out by just sticking with AYANA procedures. The last on on the topic of editing the document is whether we should have test vectors. My opinion is we are not doing anything that is new in Lake, so why add any text there? Anything that was in the test vectors for for EDHOC is good here, and I think that should suffice. From my point of view, that's about it. There are two points that might come back after I've been after I've received feedback from other people writing about Greece more generally. In particular, I mean, now that we are already renaming, we can probably also take what they're doing in the IAB document that is not to treat Grease as an acronym because that creates a lot of expansion topics and just tell it, yeah. It's about the thing that you put on a machine that that keeps working, that is not an acronym. And that makes things way easier. And, the other as, as a thing where we're deviating so far from what the general recommendations are is that this document says, if you see grease on the wire, maybe put some in your message as well. And that is recommended against in the IAB document, so maybe that could be relaxed. You see something that you don't process, that's a good indication that we are not on the limit of what you can do and maybe put some more grease on it. Yeah. That's about it from my point of view. Thanks, f happy to process any comments now or just put those here so that,

[00:42:10] **Giovanni Fedrzeski**: yeah,

[00:42:11] **Christian Amsüss**: when those are acted on, we've talked about them before. Thank you.

[00:42:16] **Renzo Navas**: Thank you, Christian. So the next one, it's with remote attestation. Sorry. You, Sean, you have five minutes. Okay.

[00:42:37] **Yuxuan**: Hi. I'm, And this is about the updates of the drive remote attestation or EDHOC. Thank you. Okay. Yep. Okay. So the draft has been updated twice. And for the version five, we have presented once in the interim meeting in May. But just in case for the people who did not attend, I will, today, present the changes since the last IETF. So one of the changes is that now in section six, we have all the possible examples of the attestation over EDHOC, and, also, we have reduced the dimensions from three to two. As you can see in the subsection subsections in in section six, that is because the third dimension is never used, and we think it's quite redundant to say. And for now, we have the two dimensions. The first one is the target, which means the attester could be either the EDHOC initiator or the EDHOC responder. And the second dimension is the model that we used could be either the background check model or the passport model. So now we have all the four possible possibilities in the draft. And after completing these four examples, our draft now allows both the intra handshake and post handshake attestation. And as you can see on the left, this this is the one for intra handshake attestation because we have the evidence sent in message three. And then for on the right, we have the post handshake attestation because we have the evidence sent in message four, which is after the EDHOC handshake. And, also, based on the verification results that we have presented before, we have added an authorization binder, which is to bind the evidence with the authentication sanction. So now as you can see in the figures, we also have the attestation binder indicated in the in the figures.

[00:44:33] **Malisa Vucinic**: Do you want to take questions now or yes?

[00:44:36] **Yuxuan**: I I only have five minutes maybe after. But I I'll finish very fast. Yeah. So as I just mentioned for the attestation binder, because you just saw that the evidence is sent in ventures message three in intra handshake attestation and message four in post handshake attestation. So, actually, the attestation binder defined for these two are different. So it's for the post handcheck attestation, the attestation binder is just derived by the EDHOC exporter because we already have all the key materials. And for the intro handcheck attestation, the binder is defined by the key derivation with the hash of the previous messages and also the ID quite eye. So because they are defined different, so we now also give them different names. And then it's about the editorials and clarifications based on some reviews. Thanks for the reviewers. And, also, during this section, we got the some feed feedback from Gabriel. And thanks for his review, and we will address this in the next quarter. And, also, we will share the working group once we address them. And also, have reviewed the draft with Göran together, though it's not finished yet. We are continuing. And but there's gonna be one change in the structure. We're gonna remove the subsections of five dot one and five dot two because there are actually only one sentence in this subsections, so we thought it's quite redundant, and they are explained in the other other places in the draft. So now the section file file will be only the definitions of the new EAD items that we defined in for our authorization over EDHOC. And then the two subsections are for the different models that's gonna use. Yep. And I think that's all. Thank you.

[00:46:29] **Malisa Vucinic**: Thank you, Yuxuan. So we have Sam in the queue.

[00:46:33] **John Preuß Mattsson**: Sam,

[00:46:37] **Usama**: what are you dressed in? I already raised the issue in the last two meetings. And for quite some meetings, I have been mentioning that who is actually going to benefit from this this work? Who in the industry actually needs this work? And the reason I'm asking is that there was a conflict on our results and your results, and we are firm on our results and for the equivalent of that for a tested TLS now. Our CV exists. Our paper is out there, and our claim is that the same attack that applies on a tested TLS also applies on a tested EDHOC. And another concern that I have is it's not a one time thing that you do at a station. If you understand, actually, it gives you at one point in time what was the status of that device, and one time attestation is clearly insufficient. It gives you only at that if you are talking about at seventeen seventeen, that's the time right now.

[00:47:35] **Malisa Vucinic**: One minute. So please

[00:47:37] **Usama**: Sure. So so what I'm trying to say is that if I take the evidence at seventeen seventeen right now, it will not be applicable even one second after or one minute after. You have to do it repeatedly, and I see no value, in fact, in other than the attacks itself, I see absolutely no value in doing intra handshake because absolute ultimately, you have to do it repeatedly, which is the post handshake. And, actually, then what is really the value of intra handshake despite these attacks?

[00:48:05] **Malisa Vucinic**: And So I will interrupt you there. There are several points that you raised that are kind of orthogonal. I would I would like to give floor to for comment

[00:48:17] **Göran Selander**: before So one user of AirDoc is is and they use this in their in their locks when they unlock sort of physical interactions with the lock. So they run the handshake every time they unlock the lock. So they do authentication at the same time as they do at the station. Sorry? So, I mean, we are proposing two models. We are waiting for input on I mean, is a topic for discussion. So are are we doing intra handshake or post handshake? That's a discussion topic. We have both. But you asked for an application. The application one application is physical interaction with a physical object where you're doing authentication each time.

[00:49:11] **Usama**: So if I may add, what I the reason I was asking was that if you give us one concrete implementation, we give you a concrete and show the working group a concrete attack on a real implementation, not just by formal methods. Just forget about a test t l s two attached attached EDHOC and our paper and so on. So we will give you if you give us one implementation, we will give you a concrete attack for the working group to see by itself as an evident.

[00:49:36] **Malisa Vucinic**: Okay. Thank you, Simon. So I would just like to remind the working group that we had an interim meeting two months ago, I believe, where we designated an independent evaluator to examine the formal verification work concerning this draft and the work that some of you have been leading. The follow-up of that work was that the model or the artifacts were not published. Are they available now, even not publicly, but only for the sake of the independent evaluator?

[00:50:11] **Usama**: So I'm I'm I'm saying that put that into rubbish. Forget about that. Give us one concrete implementation. And independent of the formal analysis, we will give you one concrete attack on that specific implementation. So is if I understood, Yukshon, in the hackathon, there is one concrete implementation. Give us the concrete link and send it on the list. We will give you one concrete attack trace on that independent of formal analysis. Nobody needs to know anything about what that was.

[00:50:40] **Malisa Vucinic**: That's perfect. Let's take that offline. Yeah. Let's take that offline. I I believe we can provide that, and I believe you, Sean, and the team have an implementation available that they can provide.

[00:50:50] **Yuxuan**: So Yeah. Sure.

[00:50:52] **Malisa Vucinic**: Yeah. Thank you for for your comments.

[00:50:55] **Elsa**: Thank you. Thank you.

[00:51:00] **Renzo Navas**: So next one is Elsa Elsa Lopez. We have to rename many things. Elsa, you have ten minutes.

[00:51:21] **Elsa**: Hello, everyone. My name is Elsa, and I'll be presenting the updates on the EDHOC with pre shared key authentication, which has already been issued there working group last call. So this presentation is about the changes that were included through the revision for the working group last call as well as some changes and of some comments that KEMe up during the hackathon this weekend. Yep. So I'll I'll go through them. So there was one issue, regarding whether the PSK was, should be associated with a hash function or, with a cipher set. And there are different, advantages and disadvantages of either or. Mainly, associating it with hash function allows to use different cipher sheets as long as they use the same hash function, which this comes in handy because you don't need to reprovision the PSK if you want to change the cipher sheet. Then regarding, well, agility, same. It allows to migrate cipher sheets instead of reprovisioning the PSK, which allows for simple negotiation. One advantage of the cipher sheet, though, would be that it allows for shorter PSK keys, which might be beneficial in some contexts. But all in all, since we are targeting constraint devices and sometimes reprovisioning might be not easy, what was suggested in version eight was to go for the hash function association, as stated in section 9.5. And also in the email thread, there's a discussion, regarding this. Another issue was regarding the resumption PSKs and, the application profiles. So Eric mentioned, in the email thread, whether we had considered allowing parties to negotiate, the use of resumption, for example, through EAD labels instead of, making it mandatory. He also mentioned some that we were using some terms regarding stronger or weaker security guarantee guarantees, which is not very precise since there's no such definition. And there was also a comment regarding the non zero probability of generating the same RKIT value for different PSKs. So these issues were addressed in the new version. So for instance, we refer to the draft IPF, well, the draft, the application profile's draft, instead of creating, like, a new AD items. So we state that the support for resumption might be indicated using, means defined in, the application profile as draft. We also removed these stronger, weaker statements since, indeed, they did not make a lot of sense. And then there were some changes regarding this PSK resumption to make it coherent with the hash function association. So we state this is in section nine point five and six of the draft. We state that, yeah, each PSK is binded to a specific key duration function through an associate associated has algorithm. And regarding the length value, it is stated in the draft that the default is two bytes. Nevertheless, this can be changed through the application profile. Yep. And the reason why it was chosen to be two bytes is a balance between the bytes transferred in the wire and the probability of collision, and we reached the conclusion that two bytes was okay for this purpose. Then there was also some we addressed some comments regarding what were the benefits of using the bireference, for the IDCred PSK. So this, can be found can be find found in section three of the draft. So indeed, PSKs need to be tied to an identity and some other security context. And this using this by reference allows to, keep the ID code PSK as minimal as possible. And it allows EDHOC PSK to minimize the overhead for PSK identification while still con maintaining flexibility for identity and contextual information. As for our score, Eric also mentioned that the spec in draft version seven was not mentioning, yeah, whether our score could be used to send a message for or not. This was stated in section eight. So we wrote that, in fact, EDHOC well, EDHOC can be used with a score by combining EDHOC message three with the first request. Now in EDHOC PSK message four, it's needed for authentication of the responder. However, this combined delivery, it's still applicable for EDHOC PSK. Yeah. However, know that in this case, the responder is not authenticated until the initiator has verified, the matching score response. There was also another issue raised, in the security considerations. So, again, Eric mentioned that in the security section, we were not mentioning the lack of post compromise integrity. So in section nine, we addressed this, and we stated that EDHOC PSK, when used for session resumption, it does provide post compromised security. However, this property only applies when resumption is used, and new resumption keys are derived for each session. So it does not apply when the long lived external PSKs were used directly across sessions without key rotation. We also updated the test vectors. So there were some we we changed some names. For example, there there was an incorrect naming of IDKRED PSK kit, so this was changed to kit length. And since the kit length was defined to be two bytes by default, we updated the test vectors to reflect this since they were calculated using a one byte kit. And finally, this last issue was was discussed during the hackathon. So, yeah, there were some comments on whether the responder should send some sort of identity identifier in message two that would allow the initiator to select the correct PSK and avoid checking for different PSKs. So following what it's done in PLS 1.2, there was a comment on including a hint with some sort of reference to the identity of the responder in message two. So this can be done either by putting the hint in the EID or by including it as part of the plain text. But still, this could be an option it's an optional value. Now there's some discussion in the working group mail, list. Seems like, option one could be less in invasive, since well, we wouldn't need to change the the specters or the formal analysis. And given that it's still an optional value, it might be a good idea to keep it as in the EAD value. Now it's true that option two keeps it more similar to the RFC 95, 28 of EDHOC. So what there's still, if someone has, opinions, they can reply to the, mailing list. And, yes, for the next steps, this, last change, will be published in a new version together with the comments from the working group last call. Thank you also, Erica and Marco, for the reviews. They were very useful. And this well, this was also done during the hackathon. We merged this EDHOC PSK authentication method into the EDHOC Lakers REST implementation. We might need to change this last bit, and that's all. Thank you.

[01:00:16] **Renzo Navas**: Thank you, Elsa. So one minute if you somebody wants to comment something. No. So thank you. So the next There

[01:00:29] **Malisa Vucinic**: was a question in the

[01:00:30] **Renzo Navas**: Ah, sorry. A question in the chat. Jonathan. Wonder if if there is an issue where by changing the hint, you could change which key was selected.

[01:00:43] **Elsa**: Sorry. Can you repeat?

[01:00:44] **Renzo Navas**: Yes. I wonder if there is an issue where by changing the hint, you could change which key was selected.

[01:00:53] **Elsa**: Which key was selected to send to the responder? Or like, I'm I'm not sure. Like this ah.

[01:01:00] **Jonathan**: Sorry. This was just a, like, thought. Can you go back one slide? Hold on. To the to the yeah. If you're picking an identity by with a hint, then could I have presumably different identities use different keys, and therefore, I can change which key is used by changing the hint?

[01:01:25] **Elsa**: Like, the thing is that the the PSKs, when provisioned to the peers, it should already include some context to, like, with whom can you use this PSK, like, the hash algorithm that you're using, etcetera. So this hint was used as again, that's why that it's an optional value because this can work without it, but it could be used as a way to, yeah, simplify the selection of the PSK and also in case that the PSK is used with different responders. So for example, yeah, it would avoid the responder needing to check for different PSKs when the message three is sent. But, yeah, like, these PSKs should already be provisioned.

[01:02:10] **Jonathan**: But you so so I couldn't have different people using the same hint in different places.

[01:02:18] **Elsa**: Like,

[01:02:20] **Jonathan**: I I'm just thinking of, like because if it's a hint, then in theory, it can collide. And so if you can end up with two different keys having either the same hint or two different hints pointing to the same key, you end up with confusion attacks.

[01:02:39] **Göran Selander**: It's a thought.

[01:02:40] **Jonathan**: May might not apply at all. Just

[01:02:43] **Malisa Vucinic**: k. So we have John in the queue.

[01:02:46] **John Preuß Mattsson**: Yeah. Yeah. Just pointing out it's the same as in tls1.two. I don't I don't think I've seen any attacks on TLS one or two, but but could could be. I think a benefit with using this as a EAD is it is not in this draft, and we can discuss these things for for a long time because they they might definitely be confusion attacks as you know, not in the sense.

[01:03:18] **Renzo Navas**: Okay. The thank you for the comments. Thank you. Thank you, Elsa. So next one is Clemont, edhoc PSK with ephemeral KEM, a formal verification using Sapic+. Clement, you will have ten minutes, and with with the clicker, you can change slides.

[01:03:47] **Clement**: Hello, everyone. My name is Clement, and I am talking today about Cypher suites, post quantum resistance Cypher suites, and the formal verification. So as objective and context, post quantum secure extension, ADOC are part of design team objective one. So we are questioning now how to extend the Cypher suites for post quantum consideration. So for authentication method zero, it's pretty obvious. You just replace the the signature by post quantum secure signature, for example, MLDSA. And, also, we could not no more relies on elliptic curve development, so we are supposed to use an ephemeral chem. So a partial security analysis of that have been made by Charlie Jacob and et al. So we are now interesting to do it with the PSK authentication methods, which mainly involved replacing the ephemeral different man by an ephemeral chem. So this has been proposed in the in the now adopted draft post quantum sets. So the objective here is to complement the the work of and also to give a basis for security analysis. So, also, to mention this work is a direct extension of formal analysis of edhoc PSK in a classical way. So just to remind that we only replaced the ephemera and element with some chem element. The first one being the public key of the initiator and the second one, the ciphertext generated by the the responder. Okay. So as it is an extension of formal analysis of a doc PSK, We are based on the same attacker model in the in the symbolic model. So cryptographic primitives are considered many perfect, so they could not be corrupt by the the attacker. And the adversary has a fully control over the networks. We can inject, replace, intercept message, and so on. And we also allow him some additional capabilities for confirmation important element, such as the PSK or the chem element. So to mitigate the the point of perfect primitive, We model different symmetric encryption and also chem. So the first one could be modeled as classical symmetric encryption with classical functional equation, but also with the built in, which is more of a practical point of view, allowing to model some specificity of the XOR operation. And for the CAM, it's mainly the same. We have a classical one which is closer to symmetric encryption and a more theoretical one with a complex functional equation, which allow to models to be closer to the structure of current chem with their current properties. So we we follow the the the work already established to show the same property with the the updated consideration here. So we proved the the authentication, the to the injective agreements either from the responder point of view, either from the initiator one, and also establish some confidentiality results regarding the decision key. So the two first one here about secrecy are a bit particular since we do not make any assumption on the responder or the initiator as the third one on the contrary, suppose that the initiator and the responder agreed on the PRK. A point to mention also is that in the formal analysis of educt PSK, we were having some kind of problem regarding stone now the defibrillator attacks since we were using some ephemeral diffusion man, which is no more the case here since we use a post quantum secure KEM. Finally, we also established a non key share attacks, which is, I won't say, a bit trivial, yeah, clear because the identity are bind to the credential PSK. And also regarding identity protection, we model it in a bit different ways over a pair of endpoints instead of just a particular initiator distinguishing between two responder. That's a bit closer from the security model proposed in the first And so just to to summarize quickly, we have so the different model of encryption and can allow four different theory, which are all verified. And just here to sum up the that all the property holds except with the minimal compromised element, which is detailed for each property. But this this is mainly the same result as what was obtained in the formal analysis of edhoc PSK. So I won't detail them all now. If you have any question.

[01:10:10] **Malisa Vucinic**: Thank you, So I believe is in the queue.

[01:10:17] **Usama**: You, If you go back to slide I think it was six or so yeah. This one. This one. Sorry. So the the the eight. Yeah. So what is the so you said that the compromise of PSK, PRK out, and all these keys. So what is your assumption, or what is the why do you take these as the as assumptions in the I mean, if PSK is leaked, then you have the problem. Right? So so and similarly, if the the KEM secret key is leaked, then you have the problem. So, typically, it's not the case that they are taken. So I'm trying to understand the motivation behind taking these capabilities for or extending the protocol analysis with these assumptions. Can you explain that?

[01:11:08] **Clement**: On my point of view, if you only leak, for example, PSK, you may not obtain all the secret or all the stuff from the session depending on the on the security notion we are looking to. Yeah. Sometimes we need more, like, just the PSK. We need to as I sum up in the in the table at the end, you need to to leak up the two secret element to obtain them.

[01:11:34] **Usama**: Right. But if you leak, for example, the secret key of chem, then you'll lose security. Right?

[01:11:41] **Clement**: Yeah. On the point here, but not all the the the the property. I mean

[01:11:45] **Usama**: If you if you go back to the properties that you have

[01:11:48] **Clement**: Yeah. Maybe this one.

[01:11:51] **Usama**: No. The next one. Then when you had the results.

[01:11:54] **Clement**: Table. Yeah. Okay.

[01:11:54] **Usama**: The tape yeah. This one. So, I mean, what additional information to the analysis for the PSK based EDHOC Is it giving addition to the analysis which was already done? So what do you I'm trying to understand what new insight I can get from this work. So can you explain me the new insight I would obtain by replacing Diffie Hellman by this sKEM? Is can you explain that?

[01:12:23] **Clement**: The the main point is to to obtain post quantum security.

[01:12:27] **Usama**: Sure. But but but what is the new insight for me? Like, let's forget about formal analysis. Let's say I'm a dumb engineer, so I don't know what this all of this formal analysis is. So what do I get from what I had from PSK by just having post

[01:12:41] **Malisa Vucinic**: I believe he has answered your question. These are just the properties in the post quantum model. I would like to open the queue for other questions. Okay. Is in the queue.

[01:12:53] **Vaishnavi**: Yeah. Hi, You had a slide about the equations for chem that you consider?

[01:13:01] **Clement**: Yeah. I forget to put it in the presentation. No.

[01:13:03] **Vaishnavi**: No. No. You have it in the presentation. You have something about classical versus theoretical? Yeah. Those. Yeah. So could you say something more about what the actual equations look like? What's the difference between the two?

[01:13:16] **Clement**: Yeah. So for the classical one, we are, okay, also closer for symmetric encryption.

[01:13:21] **Elsa**: Mhmm.

[01:13:22] **Clement**: I mean, the more technical one, we try to involve some kind of randomness

[01:13:28] **Vaishnavi**: Okay.

[01:13:28] **Clement**: Independently from the shared sequence. So the randomness will play the role, for example, of a secret key for the the responder. Even if it's not, it will I mean, it's a part of the secrets that's is involved theoretically to the computation of the ciphertext.

[01:13:48] **Vaishnavi**: Okay. Thanks.

[01:13:52] **Malisa Vucinic**: Okay. On behalf of the working group, would like to thank you, Clement, for doing this work and for extending the previous analysis that Decra and the team have done and presented in one of the previous meetings. So this is greatly appreciated by the group. Thank you.

[01:14:08] **Renzo Navas**: Okay. So yeah.

[01:14:12] **Malisa Vucinic**: So the next, the next slot on the agenda is the summary of the design team work, and Lorenzo will present that. Lorenzo, you have, fifteen minutes. I will Yes. Just take this twice.

[01:14:30] **Renzo Navas**: Okay. Hello. I'm I'm presenting on behalf of the design team, but this is a common work. So we decided to once ago, to form a post quantum edoc design team to to work on, yeah, going post quantum for lake. Everybody was invited. It was open call. I would today, it will gonna be a quick presentation because I want to have at least five minutes to discuss with you. So this will be very packed. Some slides, will just pass fast, but you can go to the interim meeting to see a more lengthy discussion about this. So today, I will try to make the main points because we have a bigger audience than in the interim. So first, to the left, you see the members of the design team. We do five weekly one hour meetings, then we have the interim meeting which we present the output of the design team. The goal of a design team is to well, first, we have to have a clear goal and to give this input. Our output of this entity is an input for the working group, and then the working group moves on. It can be discarded, but I think we achieve a good work. Then we do two more biweekly in between anyway. And I want to, again, publicly thank Lydia, which thanks to her work empirical work and input. She fed the discussion what we have internally and did the same thing. So we had four objectives. In theory, we needed to focus on sequentially. The first one is the definition of a set of deployment scenarios where post quantum edoc is realistically deployable. Once we have this, we wanted to make a recommendation of standardizing p q c c Cypress for edocs method zero, signature signature, and for PSK. Then a recommendation of standardizing new chem based authentication method to satisfy the deployment scenario defined in one. A recommendation means a draft or a a written. And we also say we would like to give some input to crypto forum research group given the, like, requirements, yet potentially giving them the input from the scenarios we define in one. What do we mean by lightweight, etcetera? So what what do we do? Six minutes to objective one, this is very lengthy because we in all the meetings we did, we mostly work on this objective one. We took many iterations to find something which we could build upon. So I think this was a great work. So Lydia take Lydia took mostly the lead in the empirical part. We took as a basis the the nomenclature from seven to to eight bits, and we focus on three constraint. Memory constraints on RAM and flash, link layer max MTU constraints, and effective link bit rate. So playing with this type of constraint, we try to define scenarios. Okay? So this this maybe I will go quick. But so Lydia took an empirical approach because, Lydia, you have a real implementation. Sometimes you also do assumption on on an Excel table for also CPU processing. So what which method were evaluated? Signature, PSK PSK authenticate CHEM and Nike, which is yeah. Some assumptions, yeah, both parties use the same method. So, yeah, and credential for mutual authentication, I probably did reference. We try to use all the common established NIST algorithms. We also have some more some more compact that are not standardized just to see what's possible, etcetera. And and on Lydia's platform, she was using a Cortex m four, yeah, for the for the running. Let's move on. So don't don't worry. You will not see much here, but this is what gives the the memory fruit fruit footprint of putting them depending on different different options on on a on a CPU. What can we give? We assume that if you have no more than I think it was 20% free, it means the the this can be used. Because if if you have more than 50% of the RAM used only for this, we assume it's not usable. So, basically, we have to put that threshold, and we put 25. So in green, you see the the solutions that take the list. Yeah. Yes. They take the list. So you have to observe what's the minimum class in which this solution fits, and you see c one. C zero was not considered. So, basically, we can provide solutions up until c one, but not everything fits onto c one. You see, some solutions need at least c two. Then we we analyze MTU constraints. What will provide this fragmentation? So we estimated the minimum class of MTU for which there is no fermentation. So in green, in the column, you have the minimum class before having fermentation. Of course, once you go down, you still can run the protocol. You will have fragmentation. I will have to go faster. So you will have more messages. You see to the right, the number of messages it takes to complete a protocol. As you see, when are your s one, you have a lot of fragments, so you have a lot of message to pass 67, the maximum. And this was very interesting. It's total, yes, handshake time. So this will be at the addition of the CPU and the time it takes over the air to complete the protocol. A lot of assumptions, like, there is almost no packet loss. So you see the CPU will depend on the algorithm chosen and the power of the CPU. And the time on air basically will depend on the bandwidth, not the fragments because in in the assumption we did, it's basically the bandwidth. So what do we can we say? We have different sets of chosen band yes. Bandwidth CPU plus bandwidth. Sorry. The CPU is always the same here. And at some point, yes, for some so for some solutions, maybe one of either CPU or time owner will be predominant. For each each column in green, you see the fastest scheme that that's achievable on that column in green. I will go faster. Okay. One main observation, PSK and KEM based authentication provide the lowest memory overhead. So when CPU is a constraint, that's what you have to do. PSK is the lowest and then CAM based second. Signature base reduced network overhead, but, of course, increases CPU. Okay. Nike is yeah. It's a yes. Nike is also even smaller on network or higher on CPU. And we are near extremely constrained link. We will need to have this gain on network at the cost of CPU. So at the end, this table resumes the we have all this to say, okay. Which kind of scenarios are qualitatively different? We KEMe first with this. We say we have four some things are out of scope, but here, we can achieve we have solutions, and we have these four scenarios each defined by a color in which we say, okay. We can work with with this. So but, basically, in the end, we we say we also we need ChemChem, and we focus on the standardized ChemCam. We didn't go much beyond the scenarios. Sorry. ChemCam, we also need PSK, etcetera. I will not say the takeaway here. But what I want to show is, basically, we have two frontiers. One frontier in memory constraint that here we put the limit between c two and c three. And a trade off between CPU and and bandwidth, which is where you will put the the violet line, for instance. At some point when the trade off, when the time owner is costly, you you want to go to signature. So this will work yesterday. Basically, in the end, we don't have we prefer to give these guidelines with with this assumption, single hop, no packet loss, no energy, coordination board the otoscope because, of course, if you these things can influence the type of solution you want. It's it's very simple what we will say, but we have two limits which will determine at least four possible scenario because when you put the two limits, you have four subsets. So device memory, low versus mid, of course. And what can happen there that if you have low memory, signature solutions are less likely possible on low memory devices. Why we put ILX likely? Because within ten years, maybe you have more lightweight solutions. We don't know, but this will be a moving a moving target, let's say. But it's true that a signature takes more memory. And on the network, actually, with network, if you have a low if the time is not a constraints on the use case, you can basically do 1,000 fragments. So it will never be materialist constraints. Sorry. I would read the what we put because it's more clear. So network reference, you have low versus mid. You have to take an account the total handshake time, CPU, mass time on error. And this trade of CPU versus network time on air, sorry, will depend on the use case you have for application and the hardware you have. Today, just quantum is not possible on c zero RAM much less than 10 kV, or a zero that is 12 byte max max. And while Bidro, we assume is not possible, I think Bidro is possible. So this so having had this, we achieved objective two, and I'll go faster. Sorry. We conclude, we recommend s p SPM-lake-peqsuites, which provides a doc six, six, four. It's been adopted by the working group. Okay? This was decided on the interim meeting. Objective three, the same in with the the same team recommended to adopt one part of one Lydia and the team with Lydia draft. Only the part with in the interim was accepted as working group documents. For the moment mix method is out of scope now. So objective two and three were achieved. We have two working groups. Objective four is the standard for crypto form resell group. We didn't KEMe up with the only thing we could say is when the the bit rate is constrained, we will we will need compact PQC schemes. It's evident. Jan proposed this text. We will we have to work on the list maybe or offline. And I think that's it. To to to recap, objective one, we have no textual, nothing concrete, but the objective will really help us to brainstorm and discuss and move on with everything. It allow us to achieve objective two and three, which I think is I think was the two most important. Object one was the foundation for discussion. And objective four is still open still open for discussion. And, basically, whatever we will say to crypto research group, we will have to wait ten or more years to get the the results. So we will still have to work with what we have today. Sorry. One minute only for discussion. Any comments, follow-up? Oh, okay. For now, I think the design team, we we didn't decide on keep big meeting because now I think we we can go offline. Any comments on the room? Sorry. No? Okay. So we have to, yeah, to adopt the documents. Yeah. Maybe yeah. Okay. Well, I want to thank again to all the members of the design team and and Lydia especially.

[01:29:05] **Malisa Vucinic**: Yep. It's big thanks to the design team and Lorenzo who has been leading it. So with that, our next slot is the, odd KEM EDHOC draft, and the lady is the presenter. So I will stop sharing.

[01:29:27] **Renzo Navas**: You have the the clicker for

[01:29:29] **Göran Selander**: the yeah.

[01:29:36] **Lydia**: Hi. I am Lydia from, the Industrial System Institute, and I will present now this, recently adopted chem based authentication method for EDHOC. Well, just to remember, it will be the motivation behind of this draft that this, specifically this use a CAM CAM basic authentication method that provide a signal to free authentication, for Ethhoc that is, come from the same content that method three, but now, post quantum secure, reusing the same, chem that we use for a femoral case for for make the femoral also in the authentication. It is the chem, label that, Rencho present before, and we have c that can be supported in c one, class devices. And that also is can be considered faster, than signature in some specific conditions when their, bit rates are big enough, a pair of tend to fight. Well, we we can see there the in in blue is the ephemeral GEM, and then we will reuse the same structure to make authentication. But now, in Diffie Hellman, we could, makes, the service secret of the party with the public, key of the other party. They and authenticate itself directly. With authentication, we cannot make that. We need to combine security secret, then the responder need to receive the ciphertext of their own public key from the other party before of be able to to compose the service secret that can be used for authentifical itself. And this is the reason for what these two extra methods are necessary. We will review this at the finish. But in this first version, we we support these two methods to be necessary to authenticate both the responder and the initiator. Just to look a little bit here what the process is, the female KEM use it to to the key string two that this uses to encrypt the the message two. And when they initiate to receive the the responder message to can retrieve from the credential, the public key of the responder need to check that the this responder is a trust party, and then is able to encapsulate the service secret and the ciphertext that need to send back to the the responder and the new key, the key three, that they use it to implement s three. Now then the responder in the other side can from the ciphertext of the responder, compute the service secret, the same service secret that the initiator have made it, service secret of r, that will be used for the read the key, for decrypt the rest of the message, and also to to be able to authenticate itself. Notice that this key three coming from the combination of both set it female set secret and responder set secret. And then we go to the next message four and message five that are encrypted with the same key that is derived from the combination of the three service secret. The service secret of the responder, the service secret of the initiator, and the female service secret. Well, we can see here, again, the key schedule, and it's marked in green the little difference that this key schedule need to have it in comparison with the original. Well, the more important is that we change the search secret for the chemistry secret. We have these two additional methods that are message four and five, that max has been moved from message two to three to message four and five, and that the mark context are updated to include the latest available transcription hub and the message specific application data. Also, the transcription has need to be adapted, to the new message format, and a new transcription half that transcription half five is computed to make the MAC three. Notice again here that message four and five are encrypted with the same key, the same key key that is coming from the the cell cell to random key that include the three cell secret as well as the the application key. Well, to maintain network message format, key schedule and security mechanism was a decision to aim to preserve the equivalent security properties that original effort. Then have changed based on accumulated previous transcription half is using. Max are computed over message data. And transcription half, it this allow us to make the verification of the handshake integrity and authenticity and also provide this credential binding. And the most important here is that following this noise framework, its new new service secret is immediately mixed into the session state. Then the message three is encrypted with the key that it be from both the service secret of the responder and the femoral. And then because also we have a possibility to to to check the trust of the responder credential, only the responder owning this secret key can decry message three. And this is the basic to try to provide initiate initiator identity protections against, active attacks. Now a little bit about the comment that, we have received until now, regarding the Yana related comment that Brian, John, and Marcos, send it, we agree that the course algorithm registration should be managed, with this course draft, and we are happy to to help to support in this reactivation. But as maybe we should keep this section until to highlight these dependencies until this go on. Regarding the ethosypher registration, we agreed that this may be a work more specifically for the late TQ suite draft. And, yes, we will delete this. And we will soon keep the ethos method registration section to for adding the new the new method for method five, for this. Well, we was also some comments from Eric that, for sure, we need to clarify the figure two. We agree. And but was also one comment regarding the possibility to extend to a mode in which only you need detection authentication will happen. This this he put it because it potentially reduce the mess mess number of mess ups. But I think that in this aspect, we need to to see the working group is interest and identify concrete use case for this because this will weaken the security properties then, seeing that we need to to see if we want to go to this direction first. Maybe we need more feedback from more people from the working group on that. Was also some little change that they proposed once I have implemented the draft, but they're just little things that, we will check it, and we will come in the next version. And the more important that has come in later of some conversation with Rafa and then with Christian and Marcos is that was let me go back. Regarding of this, of message four and five, the conversation start, like, we are using the same key and if this is correct or not. But the conversation go on, and we start to rethinking if this message

[01:37:45] **Elsa**: is necessary

[01:37:45] **Lydia**: or not. Thank you very much for Marcos and Christian feedback. And I think that the new work is to check if this message file is mandatory or can be just optionally as message four is optionally in classical and in pressure care. We will work a little bit more on this to to come put some some things more clear. That's all. Thank you very much. And happy to receive more feedback and conversation. So reveal some this that we have today and this.

[01:38:21] **Malisa Vucinic**: Thank you, Lydia. So this is a new adopted newly adopted draft, So please review it and provide comments to the mailing list. Yep. Thank you. The next item in the agenda is preliminary formal verification of this draft, and the presenter is. So

[01:38:54] **Vaishnavi**: Yeah. Hi, everyone. Today, I'm gonna be talking about the formal verification of the draft that Lydia just talked about. So some background here. This is a draft by Lydia, Christos, Apostolos, and Ivan Hellos. Essentially, the idea was that Diffie Hellman schemes can be vulnerable to post quantum cryptanalysis. So we wanted to extend EDHOC by incorporating some quantum secure cryptography. This is done via chem schemes for key exchange and authentication. And, essentially, the draft defines a new authentication method, which is signature free in which both parties authenticate using caps. Essentially, this is the the layout of the message sequences. The things that are highlighted are the ones that are most affected by moving to KEM instead of signatures. Essentially, in the first message that the initiator sends to the responder, you have the the public ephemeral key, which is set up for the chem. And the second message from the responder contains a ciphertext, which is generated using this key and so on and so forth. And most of the other elements are basically in consistency with original Redhoc. The claim security properties as far as the draft goes are as follows. It says that the established shared session key, which is the PRK out, and all the intermediate key material is kept confidential. It allows identity protection for the initiator against active attacks. It allows identity protection for the responder, but only against passive attacks. So the adversary is not allowed to be active in that case. If the adversary is active, you lose identity protection for the responder. You have mutual authentication for the initiator and the responder. You have key confirmation about PRK out, the the established session key. You have that the handshake integrity is preserved. And in order for these properties to hold, the requirements that they have of the chem scheme are that it should satisfy in CCA two security and that the shared secret must be cryptographically bound to the recipient's public key. For the formal verification, as always, we use the basic Dolevio attacker model. What does this mean? This means that the attacker essentially controls the network. They can capture messages. They can block messages. They can modify messages. They can redirect messages, and they can replay messages. They can also masquerade as honest principles, but they can't really steal their keys unless we explicitly allow for a leak of keys. They can, of course, interact with honest principles. Honest principles will follow the protocol when they are interacting with the adversary. The adversary does not need to, but the adversary cannot break the perfect cryptography assumption. So the cryptographic primitives are assumed to be perfect, and there is no way to brute force them or to break them. In order to capture the the post quantum model, we use the the store now decrypt later model, which is often also called the harvest now decrypt later. Essentially, this means that the attacker kind of picks up all the messages that they see, keeps it with them, and then at a later point, at a later phase of the protocol, we allow them the keys to decrypt any messages which might be encrypted. The code here is written in mostly in Proverif, but also some of it in Tamarind. The question there was how to specify the chem functions. So we had a few options. The first option KEMe from this paper about chem TLS by Jonathan and Tom and other people, which was published in Esarix 2022. This perhaps, I think, if I understand correctly from what Claire mentioned, is the more theoretical MLKM kind of model. This has a slightly asymmetric feel to it. You have a randomness that's involved and essentially two different functions would generate the ciphertext and the shared key and the decapsulation function. And the the equation there is how they interact. Essentially, what is happening is that there is one function which takes in the chem public key and the randomness and generates the shared secret. And then the ciphertext function takes the shared secret along with the public key and secret key and then generates the ciphertext. And decapsulation means that you can use the ciphertext and the secret key to get back the shared secret. Right? That that was the first option. There was another option which KEMe from the work by Charlie Jakob and other people, which is from Usenix 2023. This is more of a perhaps a simpler equation. At least it takes less space to write on the slide. Essentially, what you say is that in order to create the the shared secret, you in order to create the ciphertext, you encapsulate, you know, the the the secret along with the the public key, and you decapsulate this using the secret key to get the shared secret back. This does not involve an orthogonal randomness, and this also means that the encapsulation function can only be one instead of two because you can just write down the the ciphertext as in caps of blah blah blah. The third option, in fact, was this very recent work from 2024 by CAS and, various people, which is called keeping up with the chems, where they talk about, the various binding, possibilities that you can have for theoretical chem implementations. And, they basically detail a version of, what binding options you can provide to these various functions, depending on your use case. And, there's a Tamarind library for this, which means that you can set a variety of behavioral parameters. And, essentially, it is somewhat like, you know, leaking a variety of keys. Right? You're you're basically saying, I can have this binding attack, but not that binding attack, and this is the level of binding that I actually possess as part of this sKEM scheme. And then see exactly what level of binding you require in order for your properties to be satisfied, which allows you more freedom and flexibility. Maybe not now, but in the future when we have a a bevy of chem schemes to choose from, and we can choose the exact one that satisfies our requirements. So what all did we verify? This work is still in progress, but what we have verified so far is that the session key and all the intermediate key material is indeed kept secret and confidential. We have mutual authentication and explicit key confirmation only at the end of the protocol. We cannot achieve this before message two because the responder does not really have any clue about who the initiator is. We have injective agreement on identities, on connection identifiers, on the ephemeral keys, the session key as well in both directions from I to r and r to I. We also have perfect forward secrecy for the session key. We, as I mentioned earlier, have identity protection for I against active adversaries, but identity protection for r only against passive adversaries. Essentially, this is because ID cred r is sent to whomever pings the responder first. And if the adversity happens to ping the responder, then they get access to ID cred r. So in the model where we model this as a single initiator talking to two different responders and can the adversity detect a difference, Of course, they can if they play the the initiator rule as it were. So, essentially, this is the table that we have. One, two, and three are those three kinds of chem possibilities that we have. The first one is the chem t l s one where we have all these verified. The second one is the one where also we have all the all these verified. The third one is the is the Tamarind library, which we don't have yet. So in Proverif, we have all the code for these four columns. But right now, we are trying to work on, well, porting the code to Tamarind so that we can incorporate the count the Tamarind KEM library from three and then see exactly how much binding we can get away with, essentially. Also, this means that there are also a couple of other properties that we might want to analyze. We also want to uniformize the code, and all of that is currently in progress. So that's it, and thank you.

[01:47:32] **Malisa Vucinic**: Thank you, And just a clarifying question, is the code available?

[01:47:36] **Vaishnavi**: Not yet because we are still cleaning it up, but it will be soon.

[01:47:39] **Malisa Vucinic**: Okay. Thank you. Usama?

[01:47:41] **Usama**: Yeah. Usama to you, Preston. Could you clarify the the same question to him? Basically, like, in the table, if you go back one slide, basically, what you are showing is basically the same results in both columns and the both columns as the same as the other approaches. Mhmm. So I'm trying to kind of get an idea. Like, our charter basically says to use from TLS. I did some analysis for TLS, so I'm now reverse charter condition to to to TLS. Did you learn something useful in doing this with different models? Is there something we should update in the TLS models that we learn from here from your work, or do you think there is that both columns are representing? What is kind of your conclusion? Should we

[01:48:25] **Vaishnavi**: So so right now, the conclusion is that moving to the KEM model does not break anything. That's a useful conclusion to have because we do sacrifice signatures. Right? So that does not, you know, void any of the security properties that traditional EDHOC had. The other thing, as as Lydia and I have been talking, is perhaps that there might be other properties of interest in a PQ model, which we haven't considered. And it's

[01:48:51] **Usama**: Just to be sure, my my question was on one and two. Mhmm. If I understand correctly, one and two are different models of chem rather than from classic to SMTLs. So my question is more about one column one and column two. Yeah. I'm trying to understand, did you find some insight by using model two compared to model one? Was there any usage?

[01:49:09] **Vaishnavi**: So I can tell you that model two terminates faster.

[01:49:12] **Usama**: Okay. But in results, there is

[01:49:14] **Vaishnavi**: insight there as difference simply because we don't leak so another thing is that we don't leak any of the the randomness as was doing, for example, yet. There might be a case to be made for leaking more aspects of equation one, which has more parameters rather than equation two. And maybe then we'll find a difference, but not right now. Tom has

[01:49:39] **Malisa Vucinic**: a question. Yes?

[01:49:41] **Tom**: Hello. Hi. As one of the authors of the Kent CLS truth, I basically want to weigh on in in on this. So, really, Usama should be reading the and Dax paper who explained this very extensively. Basically, just going to confirm what you already said. The way of modeling in approach two has less binding on basically, it doesn't tie the public key to the shared secret that you encrypted, which means that, theoretically, it's possible to get the same shared secret encrypted to different people, which, can break protocols in all sorts of fun and exciting ways, and the famous docs, documentation paper is great recommended read. Anyway I

[01:50:33] **Vaishnavi**: think that's that's a useful thing to know, Tom. Thanks a lot because I think that could allow us to construct a property, and I will also go back and read that paper because I think that's where the new properties which are very chem specific show up. We don't have those yet because we are just looking at the properties from the traditional EDHOC draft which have been borrowed into this. But I think there are these small subtle properties that are more to do with the KEMera rather than EDHOC itself, which we should be looking at.

[01:51:02] **Tom**: Yes. But more in summary so Canvas and docs also compared, like, what does this mean for, like, the security proof that we did for Kent TLS because we did have this binding stuff. Right? Because TLS key schedule of Kent TLS is built on top of that, hashes together all of the public keys and cyber text that are sent. Essentially, you get binding anyway even if the Kent itself doesn't provide this. And I believe that the same should hold for our EDHOC because it also has a full transcript patch that hashes all messages. So it's doing approach two or doing approach three should basically just confirm that this is the case. So I would not expect different results, but it is very nice that you guys are taking the effort of doing this, I would say.

[01:51:49] **Vaishnavi**: I I think it's interesting because we should probably also be looking at what happens if we use weaker hash schemes, which is also something that I've been thinking of doing. Because if you have collisions in the hash and you also allow the the same shared secret to be linked to two different identities, something could go wrong. I'm not sure yet, but this is something that I've been meaning to do anyway.

[01:52:10] **Tom**: That sounds like a fun excursion, but definitely more on the academic papers

[01:52:14] **Renzo Navas**: side of it.

[01:52:14] **Malisa Vucinic**: Yes. Yes. Indeed.

[01:52:15] **Vaishnavi**: Guilty as charged. Yeah.

[01:52:17] **Malisa Vucinic**: Alright. Thank you. Thank you, Tom. Are there any questions for? If there are none, I propose we proceed with the last item on the agenda. And this is Lydia's presentation on draft- Pochero Lake-authc- Chem Signature EDHOC.

[01:52:46] **Lydia**: Well, hi again. This time, I want to present, the chem signature based approach, authentication method that can have a use case in asymmetric device constraints. I will focus just in the motivations. We know in the typical IoT deployment, many times we have a constrained device that is communicate with the less constrained peer. Then may we could exploit the different authentication methods, depends of the capabilities of these devices. Well, based on the events model that we have saw, before that are based in PQM for implementation, we have seen that the chemical certification reduce memory and computational cost. But this that this what is the reason behind? In many signature sKEM, the more cost operation is the signature, not the verification. At least this, for sure happen in MLDSA and FDSA, in Falcon. And, also, you can see similar trends in. On the other hand, in OBLP, again, need very much memory, but why need very much memories regarding the necessity of the big public and secret key that, again, if you need only to make verification, you can reduce by just by having the public key and not the secret key, and partial needed 281 kilobyte to just need 43 kilobyte in some of the OBLP methods. This is the this is the motivation base to provide this combination of authentication method when one party can authenticate with the chem, when the other party use their signature to to make this authentication. In these cases, the more constrained peer will need the ChemKey exchange, will need the ChemBasys authentication, and, about signature just need the verification operation. And the less constrained peer will use, again, the ChemKey exchange, the signature based authentication, but now need both signature and verification operation. The expected benefit is that we could exploit this asymmetric device capability. We could avoid PQ signature generation on constrained devices, reduce memory and computational recruitment. And, also, when we use compact signature, we could reduce network overhead. We can see in this method c n seven in the constraint part, the constraint device will be running the verification of the signature now with Falcon in devices c one. And we could also use OBLP or SQSync in c two devices. If you want to understand more these tables, you should go to the presentation of Renzo that is take it in the same basic of the of this design team work. And the change from the to the signature will need a very little modification, just following the same approach that the method three, two, and one of original have it in the way that they said it they said it secret are combining or not dependent if you have signature or, or you have a KEMpaign based authentication. And, also, many little change will be made in the, in the guest chain. That's all. Looking for feedback or if any adoption you you want.

[01:56:21] **Malisa Vucinic**: So I would first like to understand, how many people have read the draft. Okay. I see a couple of hands. Not enough. Are there any comments, regarding the relevance of this to lake, whether we should, proceed with the standardization of this additional method?

[01:56:57] **Göran Selander**: Yeah. So I you had a previous question whether we should look at unilateral authentication, and I think this is much more important than than that. And in particular, if we can make use of the asymmetric properties and so we would need both both mode both both the ChemSig and the SigChem because depending on which party needs identity protection and which party is constrained. So so it's it's both or none, but I think this is something that way we should work on. Maybe not top priority, but yes.

[01:57:31] **Malisa Vucinic**: Okay. Thank you, Göran.

[01:57:33] **Lydia**: Just to notice that it is proposal is two, method six and seven that have these two combination is, for both parties. K.

[01:57:43] **Malisa Vucinic**: So we will need more people to to raise their opinions before proceeding with the adoption call, and but we can continue the discussions on the list. I propose we do that. With that, we are three minutes early. That's not bad for a two hour meeting. Yeah. Do we have any other business in the group? I hear none. I propose we adjourn. Thank you all for a productive meeting. Let's keep the discussions on the mailing list. Thank you.