Automatic IETF Minutes

Markdown Version

Session Date/Time: 20 Mar 2026 06:00

Marco Tiloca: Top of the hour now for me too. So let's get started. Uh, hi and welcome, everyone. This is the CORE Working Group session at IETF 115. Um, I am Marco Tiloca. My co-chairs are Carsten Bormann, also online, and Jaime Jiménez on site.

Uh, yeah, as usual, we assume especially active participants to have read the drafts, at least in the agenda for today. We try to use this time for, um, effective high-bandwidth discussion to progress the documents. Uh, your participation is collected automatically. If you are there on site, be sure to log in, in Meetecho. Uh, we have two minutes takers at least: Christian and Rikard. Uh, thanks a lot. Uh, please everyone, help out. The link is in the chat.

Okay, and this is Note Well. You have seen this before this week, I suppose. Uh, it's supposed to be, at this point, just a reminder of the policies and process we follow here that you have already accepted to follow by participating in this meeting and this session. Uh, it's particularly about declaring your personal knowledge of IPR, if you have any, or refraining from participating in related technical discussion and our code of conduct. So please be nice and professional with one another. If you have questions, ask the Working Group chairs or area director.

Um, a few practicalities: we've been recorded. Uh, if you are participating there on site, please join the session on Meetecho and ask to join the queue, um, on the Meetecho mobile tool before going to the mic. For remote participants, try to use headphones, please. Uh, and if you really can't talk or it doesn't work well for you, uh, you can write your question in the chat; it would be relayed to the mic. I'll be paying attention to the chat.

Uh, so this is the agenda for today. It doesn't necessarily reflect the, um, status of the documents in terms of process, but we try to have back-to-back documents related to one another and to minimize the change of speaker. Uh, we have a little bit more flex time than usual as a safety buffer in the end. But we start with, um, a sequence of back-to-back slots from Carsten about CORECONF, touching different documents, and corrections and clarifications for CoAP. Um, we have a very related document also from Christian, URI-path abbreviation for CoAP. Um, Jaime on site presents updates on the pub-sub document and Carles about CoAP over the Bundle Protocol. Uh, then we enter into the OSCORE territory. Rikard will cover KUDOS, Key Update procedure for OSCORE, and I conclude with the document on the OSCORE-capable proxies and the document for obfuscating the OSCORE option. Does anyone want to bash this agenda?

Heard/reading none. Let's continue with the document status, um, with what happened since, uh, Montreal. Uh, on documents approved for publication: all those shown in this slide were approved already in Montreal, but the first two ones here have entered and advanced, uh, the editor's queue, and they are right now in AUTH48. And now the process is split into two halves about approving the content and the format. And the content is fully approved for the second one here: DTLS-ALPN. Uh, but I'm confident they can be actually published in the very near future. And then we also have H-REF still in the editor's queue.

Um, then newly approved for publication since Montreal: we have [draft-ietf-core-yang-sid] and [draft-ietf-core-sid] under the CORECONF cluster that started as an informational document, eventually was approved to be standard track. Um, and the two initial documents about topics related to group communication for CoAP: first one in itself, and then the second one for the security side with protection with Group OSCORE. And they are all in the editor's queue now.

Uh, yeah, looking at what happens also in other working groups with related documents: there have been two documents in ACE recently approved for publication as to the distribution of key material for Group OSCORE and the configuration and setup of OSCORE groups using the ACE framework for the sake of access control and authorization. And they are also both in the editor's queue.

Uh, so back to CORE. On what passed Working Group Last Call, we have the pub-sub document, now in version 19, that Jaime is going to present during this session. Uh, comments from Working Group Last Call should have been addressed, so if all is fine, this can likely enter the shepherding phase soon. And then we have the conditional attributes document, for which a version 12 was submitted, uh, when the submission system reopened, uh, addressing most of the open issues. There is still one outstanding issue um, around to handle; it will probably be a topic for an interim meeting in the near future.

Uh, and looking at related documents in other working groups, um, still at ACE, there is, um, another document about key provisioning, this time in the interest of the pub-sub CoAP architecture. That document completed the Working Group Last Call and is basically now on hold waiting for the core document about pub-sub to be sent to the IESG, since it's a normative reference. And after that, that document can also take the same path. Uh, there's also related document in SCHC, uh, obsoleting actually 8824, in spite of the document name, for using SCHC for header compression in CoAP. Uh, the Working Group Last Call was completed, even though it's not officially declared ended. Um, so we'll leave that to the discretion of the chairs to progress that. That's where the document is right now.

Uh, back to CORE. On yet other documents, there have been two ones that received minor updates at this latest round, so they are not in this session. Please have a look at those. Um, we have recently adopted three documents: one is under the CORECONF cluster, YANG metadata, that Carsten will cover later today. And there are two more on non-traditional responses and CoAP over GATT that are both not covered today. Uh, and then we have made some updates on two individual submissions, and one of those is the last item in the agenda for today.

Also other documents in working groups other than CORE worth mentioning. ACE again: there has been updates on two transport profiles of ACE related to EDHOC and OSCORE and on Group OSCORE. Um, and also on the use of OSCORE for protecting EST communication.

Uh, yeah, and happy to show this slide again. Uh, thank you very much to all the spontaneous reviewers for the working group that covered a really a lot of documents. Uh, I hope I didn't forget anything here. Uh, we owe you one ducky per review. We'll make it up for that, um, in Vienna, hopefully. Uh, we are doing some bookkeeping about this for sure. Uh, and a lot of activity on the GitHub. It doesn't have to be a full, detailed top-to-bottom review. If you read one or two sections alone and you have targeted comments, please don't hesitate, send a message to the list. This is really important. Um, and thanks for the reviews so far.

Uh, okay, and we have already planned and booked, actually, the next series of interim meetings for CORE, um, resuming in about a month from now, starting on April 22nd. Uh, same cadence, same time, and we'll continue like that every other Wednesday until IETF 126.

Uh, that should cover the document status and working group status updates. So, any question or comment before we get into the document presentations?

I guess not. So, it's on Carsten.

Carsten Bormann: Okay, I think I have pressed all buttons I have to press. Uh, sometimes you have to press a few more buttons than you think should be needed. So, um, I will talk about various CORECONF-related, uh, uh, items and then will go to corrections and clarifications.

Um, I hope I don't need the 34 minutes, the 35 minutes that are up there in the timer. So, first of all, on the CORECONF side, we have had a lot of discussion about, uh, the choice case exception that is needed to get the, the, identifiers that we use in SID files. And, um, I think we now have reached a conclusion uh, what we need to do. There's an errata report, uh, being prepared that adds the boldfaced text to two YANG descriptions in the YANG models. And, uh, yeah, that appears to be consensus. And I think it's a good idea to actually, uh, massage the, the errata report a little bit. So this is currently as a pull request in the YANG-CBOR repository of the CORE Working Group. Uh, it's a pull request because GitHub makes it really easy to put in comments on a pull request. So if, if you have comments on this, um, uh, please, uh, just make a comment on the pull request. Uh, we probably will send the actual errata report, uh, when we have repaired the remaining issue in Pyang. So Pyang is currently not fully consistent with 9254 and 9595 when it comes to SID file generation. And we still have some implementation work to do. Of course, we should look at other implementations as well, but Pyang is likely going to be the tool that will be used to generate most SID files, so we need to make sure that Pyang does the right thing. Any questions about that?

Okay. Second item on the list: we haven't had a need to actually modify much in the CoMI document, except for one thing. CoMI is actually old enough that it used used RESTCONF YANG data and not SX structure, um, to describe the one item of data in flight that is defined in the document. Uh, so again, this is old enough that we didn't have the problem details RFC, RFC 9290. Um, so we wrote up the structure um, in the form of, of a YANG model for these error reports. We don't want to change that, but we want to go from the now slightly deprecated RESTCONF YANG data, uh, YANG extension to the SX structure extension. So we made this change in the document. It would be nice to get some implementer feedback that we have done this right, um, and, uh, yeah, then we, we should be pretty much done with the CoMI work.

So looking at the chat, Vojtech points out that Laurentin already contributed changes to Pyang. I think these, there was still some ongoing discussion of those changes, um, so yeah, let's, let's check this offline. We are making progress here, um, but I think it's good for, for the community to look at that. And actually I, I should take the opportunity to point out we are getting a lot of support, uh, from, uh, the, the Czech NIC, uh, from people like Vojtech who is in the chat right now and Maria. So this really helps with completing, uh, this item of work.

Okay. Any questions on CoMI?

Then let's talk about the two new documents. As Marco pointed out, the YANG metadata draft is now a Working Group, um, document, dash-00. Uh, so the background is RFC 7952, uh, 50 is YANG, 51 is YANG JSON. 52 defines how to do metadata annotations, which are essentially using the attractive feature of XML to allow attributes on elements. And this is made available in the form of metadata annotations. There's a way in your YANG module to say what, what metadata annotations this module provides. And the fun part about it is that you can attach these metadata annotations to completely unrelated, uh, to data governed by completely unrelated YANG models. So this is a very good way to, to, after the fact, add some, some information like provenance or or timestamp information or things like that, uh, that has not been foreseen by the original YANG data model. So this was defined for YANG XML and YANG JSON and not for YANG CBOR. Um, in contrast to the YANG JSON version, which is really complicated, it turns out that doing this in, in, CBOR is almost trivial. Um, so the document is pretty simple and uh, currently it doesn't really look like we will have to do a lot more development on that. I think the remaining question is how do you actually signal the capability and the fact that some metadata are in a YANG CBOR object. So that, that's probably where we will have the next discussions, uh, but the, the actual functionality of including metadata is added to YANG CBOR by defining a tag. So we are currently provisionally using the number 109. And, uh, you essentially can, can take any YANG CBOR item and replace it by this tag, which is has a content of an array, and the array is a metadata map and the original instance representation. So that provides a very simple way to intersperse, um, the metadata. And right now it seems that that's actually all we need besides defining the media type information. So this is, this already looks pretty stable and uh, we could make a call for implementations at this point in time. Uh, so the next steps that I'm looking forward to is getting some reports from implementers that they actually did use this and were able to represent metadata that they also can represent in YANG XML and YANG JSON. And together with the signaling aspect, the media type parameters probably, uh, this should actually become ready for Working Group Last Call pretty soon. And of course, we want to involve the NETMOD working group in this process, keep them informed of where we are so we don't get a late surprise. Um, so this, this document might be on a pretty fast track, um, if we get input from implementers. Any questions on YANG metadata?

Okay, then let's talk about the the other YANG CBOR project, which isn't quite there yet, uh, but we probably will ask for working group adoption in the period between now and Vienna. Um, so, um, YANG is a text-based, um, representation, uh, both in its original XML form and in the JSON form that was added to it. Um, and even binary data is represented by base-64ing it, um, in the XML and the JSON. But in CBOR we can have binary data and we are using that for the built-in type binary, of course. Um, but there are other data types that we actually want to handle in binary form, and that's what this stand-in tags document is about. So if you look on the right side of the slide, there's a little table. These are not all of them, but there are a few derived types defined by RFC 9911, which is the recent update to 6991, which is the not-so-recent update to 6021, I forget. Anyway, so these are kind of the predefined types that the YANG ecosystem defines for you. And obviously Date and Time is a really important predefined type. There are others like UUID and Mac address and dotted quads, which are used for router IDs, IPv6 addresses, and so on. So these are, as I said, text-based in YANG, um, but we can represent them in CBOR in binary form. And, uh, yeah, so Date and Time is Tag 1 in CBOR, UUID is Tag 37. Uh, we probably need to define new, two new tags for Mac address and dotted quad because we don't have those. IP addresses are Tag 54. And we directly want to use these tags to do the stand-in for the text-based data that you would find in the other representation formats and that you do find in CBOR today unless you enable this mechanism. Um, so Vojtech says you most likely meant RFC 6991. Yeah, that's the predecessor to 9911 that we are now using. So 9911 has a minor but pretty important corrections in the date and time information, and that's probably what we want to start out from for Tag 1.

So, um, what we still need to understand is what exactly is the processing model. So what combinations of components do we cater for? Um, in the simplest case, you have a YANG client, um, or NETCONF client, RESTCONF client, CoMI client, that uses information from a server. And, uh, there it's relatively simple because the, the two can, can actually negotiate when setting up their connection, um, and the question is where do we do this negotiation? Is it just agreeing on a media type, um, which we could even do with existing content negotiation mechanisms, uh, or do we need some special support? Do we put this into the YANG library mechanism? This is not entirely understood. What we have found out in, in the recent discussion is that we probably want to have a file, um, that describes all those stand-ins. So essentially the content of the table on the top right of this slide, uh, that would become a stand-in file and that would be exchanged between client and server to make sure that there is agreement on what stand-in tags are in use. Because the list of stand-in tags is always going to grow, and we have to make sure that both sides understand those stand-in tags. So, um, the next steps are nailing down this processing model, fully defining the the structure and content of the stand-in file. And, uh, yeah, then we should be able to do a call for adoption, and then we essentially enter the same sequence of events that metadata is in. So we will try to get implementation reports and do the working group work and and finally do a Working Group Last Call. Any questions about that?

Christian Amsüss: Christian Amsüss just about, um, about linking this and the metadata aspect. Uh, could those use the same, um, negotiation mechanism, because they're really both about: I do support this tag and then you can use it.

Carsten Bormann: Yes. Um, we probably want to do the negotiation in terms of the YANG ecosystem. And in the YANG ecosystem, metadata is something very different from the stand-in thing, which is just a local optimization of, of the CBOR. Um, so I'm not sure that we should reduce this to "these tags are, these tags are in use," because also there may be some progression in the way we are using the tags. So Date and Time just has just received this update in 9911, um, and uh, yeah, we need to think about that. But that's a good point, that all this is driven by CBOR tags, of course, um, and we might use that as a simplifying commonality.

Marco Tiloca: Christian, you also want to raise the comment you had in the chat?

Christian Amsüss: No, that can stay in the chat. It's uh below what makes sense for for...

Carsten Bormann: Yeah, so let me answer that quickly. Um, the document, the specification 7952, of course, limits metadata to what you actually can represent in XML attributes. So it's not like somebody sat there and thought we need metadata and then started to think about how do we do this in XML, but this was just the attractive feature of XML leaking through in terms of a metadata annotation extension. And then the JSON people struggled, uh, representing this in JSON documents. Um, so, uh, you cannot put lists or or leaf-lists into metadata. These are all scalar, uh, values, because XML attributes are essentially meant for scalar values. But it's still useful. Things like timestamps and and maybe provenance information, uh, can be represented in scalar data.

Any other questions?

Yeah, and as Vojtech points out, we are not trying to, to, provide all the functionality that CBOR could. Um, there are some interesting discussions about, um, the role that any-data provides in the YANG environment in the YANG ecosystem. Um, and, um, yeah, it's sometimes difficult in YANG to control these these things properly. Um, so we are not trying to offer all the complexity and functionality of CBOR here in the metadata document. Thanks for pointing that out, Vojtech.

Any other questions?

Good, then I'll leave the CORECONF/YANG CBOR subject and go on to corrections and clarifications. So corrections and clarifications has been a working group document for a while now, and the objective is to collect corrections and clarifications to the various documents that describe CoAP and its ecosystem, so mainly on 7252, but of course also on other documents that are relevant in that space. And the idea is that we start documenting issues in the GitHub repository. Um, and once we start to understand the issues well enough to understand what we need to do, we generate pull requests, um, and we just had one successful, um, execution of this cycle. I will talk about in a minute. Um, but we have some 38, I think, issues still open. So we are not going to get bored. We have to get these issues addressed. Um, sometimes the resolution will just be, okay, that's, that issue just found out what CoAP is, which and there's no action required, uh, but in many cases it's a bit more complicated. And so for instance, one issue that we might be able to address next is issue 51, which deals with the fact that the sender of a request has a choice between using individual URI-something attributes—URI-path, URI-host, URI-query—or putting these all into a Proxy-URI option. And the assumption always is that the more constrained systems deal with fully parsed URI-something options, and the Proxy-URI is only used in those weird cases where you have to. And one of these cases might be that you have to talk to an HTTP server somewhere, and you maybe, you may need to put in options that a normal CoAP server might not understand. Anyway, so the question was, is that something that every client can do willy-nilly, or do we expect some discipline here that clients don't throw Proxy-URIs at random servers? So that's an interesting discussion and it got very concrete in the next document we will talk about, the URI-path abbreviation document. And I think we now have a better understanding for how we want to do this. There's actually text in the URI-path abbreviation document which might help us resolve issue 51.

So this is in progress. Um, let me talk about two options, two issues that we seem to have handle on. Um, so one has been the 4.02 Unprocessable Option error case, and there was something weird in the specification about that, which would have required rejecting a non-confirmable request. And it turns out that gets in the way of having 4.02 do its job in terms of negotiation between two peers, uh, which options here actually are available. And we now have written that up. And because the change is normative in effect, we need to put the change into a normative document. And the next normative document that we are probably going to complete is URI-path abbreviation, which happens to actually benefit from this, so things come together nicely. So the text that briefly was in corrections and clarifications has now moved to Appendix A of URI-path abbreviation, and the text that was in corrections and clarifications has been replaced by a stub. So that's the remaining text and we need to review this text some more and then we can probably wrap up this issue. So that was a successful execution of this cycle with an actual normative change. So URI-path abbreviation now updates 7252 because that, that is behavior that is explicitly mandated in 7252 in the CoAP specification that doesn't make sense, and we are fixing this up here. And of course, need to somehow manage the transition, so of course not all systems would immediately be able to benefit from this update.

Okay, that was issue number 52. And the last item I want to talk about is an issue that came up in multiple GitHub issues, 48 and 54, where we have text that nonsensically requires piggybacked response even if the request comes in in a non-confirmable message. And that of course doesn't work; piggyback is only available for confirmable messages. Um, so that essentially creates an inconsistency. And we now have a pull request that you are requested to look at that fixes this. Again, this is a normative change we probably have to put in somewhere. And the, there is some additional discussion on the influence of suppression. We have an RFC with a number of which I forget that allows you to control which responses are actually sent back to a non-confirmable request. And yeah, there's also a discussion of the 5.01 Not Implemented catch-all that we have adopted in CoAP, but that this requirement to send a 4.05 for an unsupported or unrecognized method um, is kind of conflicting with. So there is text there, and I would like to alert people to look at the pull request. And we may need to continue this discussion a little bit because one of the observations in the issues was that a proxy may not actually be able to do what is described as a must do um, in the current text. So we may have to put this on a slightly more realistic foot. So it's still nice to get back the "method not allowed" error in a piggybacked response, you shouldn't have to wait for it for some reason, but "nice to have" and "must do" are two different categories, so we probably want to fix that at some point.

Questions on this?

Yeah, Esko points out that this is dealing with technical debt. And indeed, we have a lot of technical debt. Um, it's all, it's all really minor issues, but still implementers notice things like that over time, and we need to slowly get rid of it. And for that, it's really useful if you occasionally look at the CORE-CLAR repository and look at the active pull requests there and at the active issues and maybe make some comments, "looks good to me" or "this has these additional problems you haven't talked about." Um, and yeah, this essentially was an ad-block here for everyone to do their little five cents for getting rid of the technical debt.

Any more questions on this?

In which case, we can go to the next presenter. So this is URI-path abbreviation, Christian.

Christian Amsüss: Yes, thank you. Um, can I apply control or will you just advance?

Carsten Bormann: Yeah, I just have to press all these various various buttons that I have to press to make that happen.

Christian Amsüss: Okay. So, URI-path abbreviation is something we started um, in summer last year, basically around the require the need of documents that they want to have especially the well-known paths, which like literally by being ".well-known" are long, um, make those shorter. I won't go into details of of the why and the how, because I've presented this at the last IETF as well, um, but talk about how we can get this done and and like what happened since the last IETF.

Um, the three things to do were basically what Carsten just walked us through, that is moving in the text around handling of the bad option. Um, there is little mechanical effect of the normative change to implementation- to implementers of this document, because uh they would still need to work with with peers that did not see the normative change. Um, but all of this only affects the what we call the tentative use of the option, that is when you don't know whether the peer supports it. And that's a rather niche case and should only be done when you have like reasonable indication that you would this would probably work, because if you basically go back and forth with a round-trip of trying the short version and it doesn't work, that is way more expensive in terms of bytes on the wire than just doing the defensive thing and sending the URI uh, all the way. So it's, it's a bit of a niche situation in this document, um, but there is a small part, that is when you don't know the precise values that work, uh where you can already simplify the implementation based on knowing that the peer at least has basically seen this document, seen this update to CoAP um, and can act accordingly.

Um, the other change that Carsten also mentioned uh was around the Proxy-URIs, where I'm not sure whether um I can agree with you on on like whether the this document really helps progress um issue 51 in CORE-CLAR, because the latest changes really meant that uh this document's requirements on the handling of URI-path of Proxy-URIs are weaker now. A change that I did, um so what what happened there, um a change that I did already for the -03 that was submitted for the cutoff was that uh working through cases when we could have a Proxy-URI conflicting with the URI-path-abbrev option, um I found that the one inconsistency we tried to cater for was when a proxy would introduce a URI- a path segment or remove a path segment, but that's not really a the concern. So proxy's inserting a path segment would have been the issue, and as as even in the case of using the option-by-option expression of the URI, that is having a Proxy-Scheme and then a maybe a URI-Host and a URI-Path, etc., um this would already have been unsupported by this document because after some um initial versions, uh we decided to not support mixing the URI-Path and the URI-path-abbrev option. It's just makes all the processing easier, and this should be a simple fix for a simple for the simple subset of the problem. So now that uh now that we apply the mandate not to change those paths consistently across URI-Path and URI-path-abbrev options, um the document became simpler, but I did not in -03 perform all the simplifications. And catching up with that in the process of also ad- addressing other comments that I received during um since publication of -03, um the document now has additional requirements removed, that is there are no requirements at all anymore for ad- for proxies, and the previous previous normative statement that a server should probably—but we know you wouldn't because it's a niche situation—um support receiving a URI-Path along with or Proxy-URI along with the um with the URI-path abbreviation could be completely removed and replaced and only for the cases where it would actually happen—which is the very niche situation of a an endpoint being addressed as a proxy even though it actually serves the requests on its own—only that case um would have to do anything special. And that is now described more precisely in in this document.

There are minor other changes, mostly editorial, um processing feedback that I got from from Carsten at Esko. I don't... do you see my slide? I don't see it but I have it on the other screen, so I can I can look at that. Okay. Um, and yeah, um I think this is basically done. Um, I'd ask the chairs whether there's anything more that they're asking from from the authors, otherwise I suggest uh we could put this into a Working Group Last Call. Thank you.

Carsten Bormann: Can you say a couple of things about implementation status?

Christian Amsüss: Um, there is one implement- um, there are so- sorry, there are two implementations. Um, I have implemented it more or less- so I have implemented the server side in aiocoap, um leaving the client side really to the application because the library cannot know um whether or not there is indication of the of the server supporting this feature. Um, there's also libcoap, um where I think John um has implemented this in in October and provided a bit of feedback that has been incorporated into this document.

Carsten Bormann: So, can can we run an interop already?

Christian Amsüss: Um, I have tried, but I could probably just pick up um John's branch um and run that. Um, I'll have to I'll have to look up whether um whether John's branch has been published so far, and if it has been, basically I can just locally take those two, or John can take the two implementations and locally use them. Um, yeah. Vojtech mentions we could do this in an um look look at look look at it in an interim, um probably as prepar- um do something as preparation for the interim, that would be my suggestion.

Carsten Bormann: Yeah, I hope in the interim we can report on the successful interop.

Christian Amsüss: Yes. Yeah. So I don't know if John is here. I don't see John. Um, yeah, I'll just try to reach him.

Carsten Bormann: Great. So, um, yeah, let's clarify this off- offline whether we can do that, but I think usually it's a good idea if you do an interoperability testing that both sides of that testing uh have a high-bandwidth communication uh going on. So that may be something we can schedule at some point, but it may be a very low-friction event, low-threshold event, um doing that. Anyway, thank you.

Any other comments or questions for Christian on this?

Next is Jaime then.

Jaime Jiménez: Okay. Do do you share, Marco, or or share?

Marco Tiloca: Well, Carsten was in control and I guess is in the process of giving you control, uh, so that...

Carsten Bormann: Well, you should be seeing the slide already. I see the slide.

Jaime Jiménez: I mean, okay. Then if you share, I don't share. And if it's okay, since we are very few here, I can just do it from the chair here. So, uh, the CoAP pub-sub draft, we have we are now on iteration 19. Um, there has been a couple of reviews by Marco and Christian and... oh, thank you, Carsten. By Marco and Christian. And I I will just basically go quickly through the changes and um maybe update a little bit on the architecture, just a reminder. So, uh, the core of the idea is that there is a broker sitting between publishers and subscribers. The subscribers put the data there with the PUT method, subscribers observe, and the broker stores and forwards those messages. So this lets sleepy, NAT-ed devices also to participate without having the need for direct reachability there, and it decouples produce and consumers. Um, on the topic resource side, there is two levels of resources. So there is the topic resource- well, there is a topic collection for discovery, and then there is a topic resource that holds configuration. So things like the name or the content format, the expiration, and others. And then the topic data, which is where the actual subscription with observe happens. And then the topic data URI does not have to be hosted at the broker; it can be pointing to another server entirely. Um, then on the life cycle, there is three states. A topic can start as half-created. Once a publisher publishes on and pushes data, it becomes fully created, and then subscribers can observe that data. Sorry, the image is a bit small, but you have it in the in the document; it's the same. Uh, then deleting a topic data sends it back to half-created state. And maybe the like a little change, and I will comment more on that, is the INITIALIZE property that now it can skip half-created and it goes directly into the created state.

So, what were the changes in the last version, um which is basically on the Working Group Last Call review. Uh, the the biggest change was the INITIALIZE. Uh, so Christian pointed out um, I think it was Christian actually, or Marco. No, it was Christian who pointed out that, uh, sending notifications without the content format uh, was an RFC 7641 violation, so we didn't- we need to have a consistent content format, and we changed that as well. Um, then on the topic data, there was a uh a problem with the uh persistence of the property, of the topic data property. Um, so basically before when you deleted the topic data, you also removed the property. So you need to create it again because publishers wouldn't be able to republish. So that that is now explicitly mutable after creation.

And then, uh, yeah, we have there is other drafts that were made normative and we just made them informative because they were blocking publication. Um, there is actually also the ACE pub-sub draft that is gonna be published earlier than this one that is also referring this one, so that is another reference issue we need to follow up on. And then, uh, another change on the response codes. So they were very strict, so we relaxed them a little bit and just refer to the original CoAP spec. Same thing for I mean, either success or errors. Uh, so basically now you the implementer can choose what they what they prefer. Similarly with clarifications, the maximum subscribers is a hint that the that the broker ultimately decides how to use. Um, and then, uh, yeah, we made it explicit that you can choose to host your your resources on a different server. And, um, yeah, I don't remember the normative statement of UNSUBSCRIBE. I don't remember that one, sorry. It's in the in the changes. And then some definition aspects. We also got, uh, the CBOR key registry as well there. So there is a CBOR key space that has these, uh, registration policy well-defined. It was already well-defined in previous versions, but we did also some a few needs there. Um, I think, uh, yeah, Christian also pointed out um, that there is some text string keys in CBOR registries that are never actually used in practice, so we dropped them. And then I think there was some also some little needs here and there with the CONF filter name. So we also edited those.

And then, basically the status is that I think the the comments from Marco and Christian has been have been addressed. Uh, Esko was, I mean even before this version, we already addressed the comments from Esko. The early review from IANA has been resolved, I believe. Also the repo has been clean up, there was a lot of old references. Um, the- so I have an implementation of the CoAP based on aiocoap of this broker, and I think it has been updated to version 19. Um, I believe maybe not fully, actually like but but at least it has been updated as well. So it matches better the the current broker specification. And then I also got a couple of weeks ago some editorial needs from Marco that I merged. So that that would require a 20, version 20 submission. And that is it, I think. So from my point of view, I think is pretty much done and um yeah, so basically is now for the in my opinion- chair hat off- is ready for the shepherd to to be taken. But let's do Q&A. That's it.

Carsten Bormann: Yeah, let me quickly point out that from the process sequence of events, the we completed the Working Group Last Call. We are still processing a few, um, details, but that that would should only take a couple of of days more. And the next step is for the shepherd to actually generate the shepherd write-up, so this is where Esko will come in again. And when we have agreement on the shepherd write-up, we can submit this to the IESG.

Jaime Jiménez: That's good. And I mean, if anybody has comments, the workflow we have with the PRs is pretty good, so if, you know, just do a PR and I will check it and commit it. I mean if it is discussion then email is good but otherwise PRs are preferred.

Marco Tiloca: Yeah, like Jaime mentioned, we need for sure the version 20, uh so that an actual new draft version includes that merged PR.

Jaime Jiménez: Yep. Correct. Well, thank you. And thank you all the reviewers for the time, by the way. I know that both you, Marco, and Christian took a really long time to go through and be thorough. So it's much appreciated. I will have to review as well and spend more cycles on that to get more of the little duckies that we have here.

Carsten Bormann: Okay, so let's get this done in the next couple of weeks. Um, thank you Jaime. And, uh, yeah, one disadvantage of this slide-giving slide control to presenters is that they can close the presentation, which defeats the mechanism that Meetecho now has uh for supporting, um, quick reuse of the media channel. Um, so the next one on the agenda is the...

Carles Gomez: Yeah, CoAP over Bundle Protocol. Sorry. Okay. Hello, everyone. My name is Carles Gomez and I'm going to present the last update of the draft entitled CoAP over Bundle Protocol (BP). My co-author is Anna Calveras and we're both from UPC. On the status of the draft, it was adopted right after Madrid, and today I'm presenting revision 02, which aims to address the comments that were received in the last meeting, and also we tried to solve the last pending to-dos in the draft. On the table of contents, we added a little bit of new content within section 11, and then we applied some internal organization within that section. Uh, but otherwise, the top-level structure of the document remains basically the same as in the previous version of the draft. So now let's go through the updates in this last revision. The first updates are in section 8.1 on CoAP blockwise transfer parameters. We already had text on the MAX_PAYLOADS parameter. As you may recall, uh, this indicates the number of consecutive blocks an endpoint can transmit without eliciting a message from the other endpoint. And uh, the default value specified in RFC 9177 is 10 for this parameter. So we added the new content which is highlighted in red here. Um, the motivation in RFC 9177 for that default value of 10 is based in turn on RFC 6928's motivation for a TCP initial window of 10 segments. The motivation actually reads as follows: "10 segments are likely to fit into queue space available at any broadband access link even when there are reasonable number of concurrent connections." And we've added that however, the previous statement assumes typical internet characteristics and TCP segment sizes. So we are dealing with CoAP over BP here and for CoAP over BP environments, the characteristics of the BP paths and CoAP message sizes involved need to be considered when setting MAX_PAYLOADS. For example, um, the characteristics of the path in a deep space environment running CoAP over BP will probably or not necessarily be the same as those of a terrestrial wireless sensor network running CoAP over BP.

Then in section 11 on securing CoAP over BP. Again, uh, we added some short new content which is basically subsection 11.3. and then we applied this structure of subsections so that 11.1 and 11.2 have the actual content was already existing, and the only new thing about those first two subsections is their titles. The first is DTLS versus OSCORE. Second one is OSCORE and BPSec. And what is new is 11.3, which is entitled Security Requirements of CoAP requests and responses over BP. So here the new content that we have is that when CoAP is carried over BP, a CoAP response should be protected with at least the same level of security as its corresponding CoAP request. Um, well, not sure if this might be sufficient. On the other hand, a few days ago Marco sent a review of the draft. Um, many thanks, Marco. Uh, this is very much appreciated. And one of the comments was about this content, and he mentioned that this text probably referred to uh the perspective of the Bundle Protocol because both DTLS and OSCORE would have their own rules to protect CoAP responses. And yeah, definitely we agree with that and we plan to make it explicit and perhaps elaborate in the next update of the draft.

Okay then, in section 12.2, we completed the content of an IANA request. Uh, the DTN working group produced RFC 9758 which, among others, creates the concept of a well-known service number, and in this document, we request the assignment of a well-known service number for CoAP in the ipn scheme URI well-known service numbers for BP version 7 registry. And yeah, we have completed the content here and also we have updated some instances throughout the draft where we refer to this request.

Then, uh, and finally, on the security considerations, there is some text that you may recall where we explain that there is a risk when a node uses message aggregation, which is that uh every single message that's the individual messages an aggregate message is composed of needs to carry the Payload Length option, which however is Class U for OSCORE, so it's unprotected. And the risk is that an attacker might perhaps infer some features of the communication based on the payload size of the messages. And uh in the last meeting, we received comments from Marco and from Martina suggesting that perhaps we might want to consider using the padding option which is defined in the Cacheable OSCORE draft. And indeed, that's a a great suggestion and thanks to both. And yeah, we have added that it is possible to mitigate this risk. And in that case, a single message would first be padded, and then the padded message would be protected with OSCORE. And the padding option is Class E for OSCORE, so it's protected with encryption and integrity protection. And even if the OSCORE protected message would still have a visible payload length, then an attacker would not be able to know uh what part of that payload length is actually corresponding to actual data or padding. Then, um, Marco also had a comment that perhaps we might want to reduce a little bit the requirement level, let's say, of using or depending exactly on the padding option as described in the Cacheable OSCORE draft, maybe rather cite it more like an example so that we could also refer to it as an informative reference rather than a normative one, which is the current state in 02. So yeah, we also agree with that and we plan to do that in the next update in revision 03.

Okay, so about next steps: yeah, the first one is addressing Marco's comments on 02. Otherwise, it appears that the document is maybe getting stable, perhaps not only in the structure, perhaps also a little bit about the content itself. Uh, we are not requesting Working Group Last Call, but uh perhaps it would be great to get maybe reviews in the current state of the document. Um, also we would like to say that we have received already lots of feedback from the DTN and the CORE working groups, and it has all been very helpful. Uh, but yeah, anyway, getting more reviews, perhaps now that we might be getting a bit more stable now, uh could also be very useful. So I think that's my last slide. I don't know if there may be any comments or questions.

Carsten Bormann: While people are queuing up for their comments and questions: quick question, what is the implementation status at this point in time?

Carles Gomez: Yeah, um, we have a section in the draft which describes details about one implementation which for the part of CoAP is based on aiocoap and then for the BP side is based on MicroDTN. And yeah, on that section there are well, there's a description of of the implementation; there are also links to GitHub. Um, so that implementation complies with one of the previous versions of the draft, so not the latest one or ones. But uh also we are in the process of getting more people involved and uh developing a bit further, updating the implementation to the latest state of the draft.

Carsten Bormann: So what would be a good time to tell people, "hey, this is now ready to implement"?

Carles Gomez: Well, uh, perhaps even now could be a good moment, um to start working on that. Uh, we are wondering whether there is something we might be missing, but uh again, the the state of the document seems to be getting stable. Um, so yeah, perhaps if anyone wants to try implement this, it would be possible to start right now. And yeah, let's hope I don't know if there will be like significant changes in the next updates of the draft, but yeah, let's say that perhaps now is already a good moment.

Carsten Bormann: So, um, yeah, I would expect that uh there will be updates of this document. Um, so we should use the submission of a new revision um as a point to consider whether this is a revision that we actually can identify as an implementation draft, as a draft that we ask people to to actually implement. So I think that that would be a good step after getting uh a few more reviews, reacting to the reviews with a new revision, and then we could either identify this as an implementation draft or maybe wait for the next revision after that. Um, so so people know they should be doing that. And uh then we can actually start thinking about interoperability um event. I'm ignoring the "time is over" thing up there because we do have some flexible uh time in this meeting, so uh we don't have to rush this. I think we should be uh creating our strategy for for moving this forward. Christian.

Christian Amsüss: Hello, Christian here. Um, thanks for updating the document with the proxying scenarios. That is really helpful in in understanding um the setup. Uh, one thing that um I would suggest for the next iteration, but I'd encourage you to to consider is um whether in in the and under the aspect of um of hiding information around the endpoints or about the the length of messages, um it might it might make sense um to also to apply security on a hop-by-hop basis in addition to the end-to-end security. Um, I can send you the links to the to the precise document that might help there. Uh, a concrete reason why I'd encourage that to happen now is because it would um also affect the the use of the of multiple messages in a single message using the payload length um when protected through OSCORE, because that might enable like packing really taking one of those bundles and packing it um and and protecting it as a whole with less consideration for individual message security.

Carles Gomez: Okay, thank you. So, um, yeah, thanks for the comment and yeah, if you can provide the pointer, the... yeah.

Marco Tiloca: It's in the chat now.

Carles Gomez: It's in the chat. Yeah, I was reading it right now. Thank you. Yeah, okay. So, yeah, I'll take a look at that as well. Thank you. Thank you very much.

Marco Tiloca: Christian, you're still in the queue. Do you want to say something more? No. Any other questions or comments for Carles? I guess not. Thanks a lot again, Carles.

Carles Gomez: Thank you.

Marco Tiloca: Next is Rikard then.

Rikard Höglund: Yes. Let me turn on the video also. So, uh, hello everyone. My name is Rikard Höglund and I would like to present some updates to this document, Key Update for OSCORE, which has now reached version 13. And just to recap what this is about: it is about renewing the master secret and master salt for OSCORE, which will in turn result in deriving new sender and recipient keys. And there can be multiple reasons you'd like to do this, for instance application policies. And we also have a related draft about OSCORE key usage limits, which um specifies uh certain recommended limits for key usage, and this is something that comes from CFRG originally, basically stating that if you use a key too many times you may actually start weakening the properties of the AEAD algorithm. Um, KUDOS doesn't change the ID Context, nor does it change the sender and recipient IDs. Uh, it's also agnostic to whatever means you used initially to you know create this OSCORE security context, whether it's EDHOC or hardcoded or um some ACE profile. Um, and essentially what you do: you start with a CTX_old, you execute KUDOS, and then you get this CTX_new, which is your brand new context with um new keys inside. Um, in version 10, we did a kind of a major redesign uh which is now more like explicitly state machine-based. Uh, other good properties about KUDOS: it can be initiated by either the client or the server. Um, also we made it robust against peers rebooting and losing state. Uh, typically it will finish in one round trip unless you know something goes wrong in terms of like messages lost or such. Uh, it's also flexible when it comes to the message flow. You do not have to have like explicit like "this is like a purely KUDOS message," but rather any CoAP message can be a KUDOS message, um so you can actually use your like normal uh traffic to also execute KUDOS.

And just to zoom in a bit, we have this extended OSCORE option to you know allow um running KUDOS, essentially, or the adding the functionality we need for KUDOS. And the key aspect here is mainly that we define the X-byte and the nonces field. So the X-byte contains the length of the nonces and also some bits, for instance: do you want to preserve observations? Do you want to run KUDOS in the forward secrecy or no forward secrecy mode? And also the KUDOS message type, so we have two message types. And just to comment on the forward secrecy and no forward secrecy mode, we do have a no forward secrecy mode for very, very constrained devices that are unable to store anything to persistent memory, meaning they cannot remember after reboot their latest CTX_new, so they always revert back to some type of bootstrap material. In such case, they can run KUDOS in the no FS mode. Uh, and um, yeah, I mean essentially what the the core of KUDOS is the exchange of two nonces N1 and N2 placed in this nonces field. Then you take the nonces together with the X-byte um and also your old key material and from that you derive um new master secret and new master salt.

Uh, we have a number of states defined for KUDOS. You can be basically in three different states: IDLE, BUSY or PENDING. And um, this is also related to the state machine; it's centered around these state- yes, or states. Um, so essentially if you start in IDLE, uh when you transition back to IDLE, that means you have com- you have uh completed a KUDOS execution and you have your new CTX_new, uh and you have also achieved key confirmation from from uh the other peer. Um, yeah, I proceed.

And this is an overview of the state machine. So you can also see the definition there on the top about divergent and convergent messages. Basically divergent message means you are offering your own nonce, you have not received the other peer's nonce. Convergent is: you're offering your own nonce but you have already received the other peer's nonce. And these uh types message types are indicated in that in the X-byte in the d-bit, setting it to 0 or 1 as appropriate. Um, and as you can see here you know um there's multiple paths you can take. I mean a typical successful KUDOS execution uh would you know basically go from PRE-IDLE to IDLE to BUSY and then you um you go back to PRE-IDLE successfully executing KUDOS. Um, now there are other paths if you have message loss or reboot or other complications. Uh, one thing to point out is if you look at the the top right kind of, there is this path from PENDING to BUSY with uh you know a lot of text above it. That is actually one path where we introduced a possible optimization uh in a previous version to be able to avoid taking that path.

Um, yeah, some updates we did now for this version: so uh one big thing we did is define the SCHC compression of the extended OSCORE option. So this content was actually previously in uh the IETF SCHC 8824 update, but we discussed this uh and decided that it's probably better to do in this document due to the relation between the documents, which will also affect which references need to be normative or informative. So considering the timeline, it's better to have this content here. Um, so what is this content? Well, basically uh it's defining um the field descriptors for SCHC. I mean, in particular here what we're introducing new is the X-byte and the nonces, right? Uh, we also have a textual description on how to handle these X and nonces subfields. Furthermore, we have IANA considerations for the SCHC compression of CoAP fields registry, where we want to register well the field X and the field nonces um under the OSCORE CoAP option. And in addition to this, we also have an updated YANG data model which now um covers the extended format of the OSCORE option.

Another update we did is we have a lot of like message flow examples just for people to understand or get a better feeling for how like KUDOS can execute, because it can be quite straightforward if everything goes correctly, but if there is some complication like a reboot or you know um running KUDOS back-to-back or message loss, uh it's good to have message flow examples. So we added one more example now where KUDOS is initiated with a request message but the final response is lost. And I can actually show that. It will also give an illustration kind of in general of how KUDOS would work. So you see this request number one being sent containing the nonce N1 and um as a response now from the server you will get a response uh containing the nonce N2, um and if you note also that response uh will be protected with the new context because at this point the server has both nonces N1 and N2 and thus it can produce CTX_new. Um, when the client receives such response, it can also derive the new context CTX_new. It will verify uh well decrypt the message practically. And if that succeeds, it can actually transition back to PRE-IDLE, deleting uh the old context. And um that's essentially like the the key update you know part where the client also receives key confirmation. Uh, however, it then continues because you would like to have uh one more uh message sent. So in this case, the client will send one more request. Uh, however, the response now from the server is lost, uh resulting in the server well resulting in the client re-sending the request again, and in this case, the uh response is successfully uh received by the client. And at this point, the server can can transition to the PRE-IDLE state and it will also have successfully finished the KUDOS execution. And by the way, we have like I mentioned we have multiple further message examples obviously also including like a vanilla completely successful execution.

Um, what's the summary and next steps? I mean at this point the design is stable. Uh, we do not plan any major modifications to the to the design of functionality. Uh, the main thing I think we've been working on is implementation. So I've been working to update our Java implementation to be aligned with this latest state machine-based design. And we did also have interest from other IETF contributors regarding implementing the new design. Um, so hopefully we will have those two implementations to interop. And we do also have an implementation in C for the Contiki-NG operating system uh that also needs to be updated to be aligned with the latest design, uh that is a later step, but we also plan to to do that. Uh, yeah, so thank you all for listening and any comments, feedback or review are are very welcome.

Marco Tiloca: Thanks, Rikard. Uh, and thanks Carsten.

Rikard Höglund: Yeah, thanks Carsten.

Marco Tiloca: Any comment or question, anyone? Okay. Francisco.

Francisco: Yeah, I see that comment in the chat saying here is a Contiki-NG implementation. That's excellent. I wasn't aware of that. Uh, that's very good. Yeah.

Rikard Höglund: Yeah, let's let's sync on that for sure.

Carsten Bormann: So again, we may be thinking about organizing some interop uh in in some form.

Rikard Höglund: Absolutely.

Carsten Bormann: Perfect.

Marco Tiloca: And thanks Christian, too. I had the memory you planned to implement it, but I wasn't sure.

Okay. Uh, I guess I'm the next one. All right, thanks Carsten. Um, so this is an update on the OSCORE-capable proxies document that was also mentioned before during Carles' presentation, now in version 6.

Yeah, as the name suggests, it essentially enables the use of OSCORE also at proxies. So not only end-to-end between client and server as originally intended, but also between client and proxy, proxy and server or two adjacent proxies. And in that respect, updates RFC 8613 and also RFC 8768 on the Hop-Limit option, defining explicitly to be um Class U for OSCORE. Uh, out of this, you have interesting side effects: there's a way to be sure to protect options um as much as possible when everything can still work, basically upgrading those from their original Class U or I to Class E. And you can also end up very easily to protect um a single CoAP message with multiple layers of OSCORE. The typical case is both end-to-end between client and server and uh also between client and adjacent proxy. Typically that's going to be the case, I expect. And it works just as well also when Group OSCORE instead is considered.

Uh, okay, on recent updates. Well, uh this was actually presented last time uh quite some time ago, uh so trying to squash updates happened since there here. Um, we added some more uh content and improved the text we had on the motivation and benefits for the update related to the CoAP Hop-Limit option. And we also clarified that uh there is an expectation for a proxy supporting OSCORE to understand the options it has to deal with when sending out um its messages, uh for the sake of the possible uh class upgrade, for example. Uh, more on the editorial point of view, we moved the section about the use cases uh to an appendix uh to make the document body uh less noisy. Uh, and on the message processing, we had a bit sparse here and there uh the deviations from the original OSCORE RFC, and now those are all collected in the same Section 3.1. Um, it's also clear how, uh, inner and outer CoAP options using the original terminology are handled uh when it's about their processing. Uh, and we also extended a bit the security considerations.

Uh, 4 to 5 was uh more a matter of minor editorial improvements. And here we are to to the present and the update made at this uh last round. Uh, we had quite a few references to update, both for IETF documents but also for um external specifications like OMA. Uh, this became up to date when referring those; now it should be correct. Uh, and revised a bit the use of uh normative language and and references to CoAP, uh even removing some thing where really uh not appropriate. Uh, we have had for a long while a section related to the use of uh SCHC header compression when uh when this method here uh is used. Uh, I found some bugs or at least some misleading text that was suggesting uh a wrong behavior about the the final use uh of the outer SCHC compression that is supposed to happen once and for all after all the OSCORE protections have been made on a message. So that should be fixed now. Um, and there is also in terms of uh language a clear distinction between the the inner and outer SCHC compression rules uh used in this context.

Uh, yeah, on more substantial update and to keep the pace with other uh documents we've been working on here. Uh, now we are covering uh also the URI-path-abbrev option that Christian presented before, um considering it as yet another option in the set of proxy-related options and uh reasoning around it, uh both for the cases where we're talking about a forward proxy or reverse proxy. But fundamentally, uh nothing new, of course, uh it's just the mutual alternative to URI-Path, and the new text about this is in the terminology uh and largely in the section describing the processing of incoming requests and and then in the ASCII-art diagram that was honestly the most difficult thing uh to update editorially.

Also something that uh Christian noted during a discussion we had in Madrid last year, I think. Um, thanks a lot for that. Uh, of course, in general, we need to have uh a non-first response uh to a certain request uh including the partial IV um from the server or proxy, at this point, that produces the response. Otherwise, we run into reuse of AEAD nonces, which is a security issue. And Christian noted that uh we were covering um automatically already almost all cases uh from the work done in other documents already, but uh um not one in particular, meaning uh when the response is protect- protected specifically with OSCORE and is not an observe notification. Uh, this document enabling proxies to do um OSCORE protection here uh is effectively enabling a case where we were not inheriting that be- that safe behavior uh automatically. And now we are defining it um explicitly in the sections related to the processing of a response from the point of view of the sender and uh and the recipient. And it's the same rationale and and line of thinking that we've always had um in OSCORE and Group OSCORE, of course.

Then Christian also gave an actual review. Thank you very much. That is really helpful. Uh, it was announced as a review of version 4. Judging from the comments and quoted text, it looked more like a review of version 1, an old version of the individual submission, even. But still, that was very helpful, thanks. Uh, we sorted it out. Uh, we addressed almost all comments. I'll come back to that. Uh, we have tried to clarify what we mean with "consumer" of an option uh for an incoming message. And we also revised the use of uh error codes or error handling um in general. Uh, so you were right: in one case 4.04 was definitely more appropriate, and in another case, we just removed like you suggested the whole error handling we were we were writing down, since uh things are just supposed to happen as the OSCORE RFC uh describes.

Uh, following also other suggestions from Christian, uh there were two uh relevant use cases that were buried uh in a section called "Other use cases." We brought them out. Now they are self-standing subsections in Appendix A. Uh, it's about using this method to enforce access control um at a proxy for the sake of identifying the client that wants to use the proxy altogether. And access control to the origin server, uh via a proxy, and in that case, the proxy still wants to identify the client and then can act as a hard firewall or instead as a rate limiter. And we also uh added a suggested reference uh when you can find more details about that. We also had text in the section about processing incoming requests on the possible enforcement at the server of uh policies for uh decrypting a request or not, for example, if hiding behind a reverse proxy. Uh, also following the recommendation from the review, now the text about that in that section um has become minimal, uh with a forward pointer to a new later subsection describing that uh a bit more uh in detail, more explanatory, uh and also with implementation considerations about that, I remember. Um, the related security considerations were also revised to be aligned uh with this update.

Uh, okay, I said we addressed almost all comments. I think we didn't touch three yet. Uh, two are editorial, and we just didn't make it in time before the cutoff to work on them properly. We will. Uh, and then there's a third one, non-editorial. Uh, it's here in the slide. Uh, so Christian was wondering if we can give any guidance at all uh to proxies about uh even when they should try establish an OSCORE association with the server if they don't have one already, and if so, if SVCB resource records can help proxies to learn about what the server can do um in the first place. So I I tried to unpack a bit the problem here. Uh, it can be a matter of uh the proxy first of all learning if uh the server supports EDHOC for the sake of uh establishment. I think that's a no-brainer. It goes down to using hopefully the same toolbox defined uh in a Lake document about that. But then it would help also for the proxy to learn about the support at the server of uh nested OSCORE protection. Uh, yeah, I think SVCB can help here. I just wonder if we can help also um in in the case of a reverse DNS lookup, thinking of uh the URI of the server provided to the proxy uh through a literal IP address instead of uh a register name. So maybe it's possible, I I don't know. And in addition, orthogonally to that, I wonder if it's worth or orthodox even uh to think about a new target attribute for uh for using a link uh of a new well-known resource at the server talking not of the resource, strictly speaking, but of the server as a whole. Uh, assuming the proxy to have learned about these things somehow, uh a possibility would be for the proxy to use uh sorry to open an OSCORE association with the server uh if it knows that the server supports OSCORE and to use EDHOC for doing that uh if it knows that the server also supports uh EDHOC. We plan to follow up on the list to reply to Christian point by point with the focus on the three unaddressed uh comments especially. Uh, on this in particular, is there any early input or opinion today already?

Christian Amsüss: Christian, um, just one um, the nested part will be tricky because uh we might discover that the server supports like two layers, but we can't and shouldn't know how many layers are in there. Uh, so um, it might be better to rely on guidance from the client. Um, and I don't I don't have any plan on how the client could provide that guidance, but um, if it should be if if there should be some initiative from the server, I think it should be prompted by the client. Or at least informed by something that the client does.

Marco Tiloca: Yeah, and even that can probably be ambiguous or or incomplete, but I agree the server can at most say, "I support nested," but not not really how many layers, at most.

Christian Amsüss: Well, it can say how many layers it supports, but it doesn't know if the client uses many layers; it won't tell the proxy how many there are.

Marco Tiloca: Sure. Thanks, but we'll follow on the list then about that. Okay. Uh, and just to mention, we have two human-generated implementations uh of this. Uh, one in Java for Californium with um a large support of um both existing uh proxy-related options. It was tested in multiple combinations um of use of OSCORE on the different communication legs and even trying it out when using Observe and EDHOC to establish the OSCORE associations upfront. Uh, one is more minimal but still uh fully functional in Contiki tested on constrained devices, uh and using OSCORE both end-to-end and between client and proxy uh at the same time.

Uh, yeah, we still have to complete addressing Christian's review as I mentioned and we plan also some more text on the client side uh to complete the handling of multiple responses to the same request uh from the from the same next stop, I would say. And we think of adding at least one more example of message exchange with a minimal chain of uh two proxies; that would be useful to show. Uh, comments and feedbacks anyway are welcome anytime. Thanks. And I wasn't following the chat really, sorry. Um, bring something up if there's anything.

If none, I can move to the next one. Should I switch to the next slide, Carsten? Maybe it's faster for me.

Carsten Bormann: Yes.

Marco Tiloca: Okay. Uh, so this is an update on an individual submission on obfuscating uh the OSCORE option, uh now in version 2. Uh, yeah, as a recap, when protecting a CoAP message with OSCORE, uh the OSCORE option is included, um and it's not encrypted uh to facilitate operation at the recipient side. So its fields are in plain and in particular the Partial IV and the KID field, including the sender sequence number uh of the sender node and its OSCORE identifier. And that can be the starting point for uh inferring behavioral patterns of endpoints or even tracking them across different network paths. So some times ago, uh this was noted, it was hoped as a possible point of update in the future to do something about this, starting with the Partial IV, but even better, um also for the KID somehow. Uh, yeah, the scope of this document is essentially about doing something about this as an intended update to the OSCORE RFC, um and it defines a method for obfuscating uh those two fields uh in the OSCORE option. Uh, the Partial IV for sure and, um as the major part of the update in this revision, uh also the KID field uh if separately explicitly agreed by the two peers. And these operations are supposed to be efficient as based on XORing with key streams uh that are derived through um an additional key defined for the security context but established once and for all uh together with the context. We are intentionally avoiding uh in-band signaling to say on a per-message basis if the method is used; that's just supposed to be uh written in the security context as part of its parameters. And this works both for OSCORE and Group OSCORE.

Uh, so as I mentioned, when the two peers establish uh the context, they have to agree on this too, like they agree on the encryption algorithm uh to use. Uh, by default, if they don't explicitly agree, this method is not used. Uh, if the context is established to use this method, then it's used to obfuscate the OSCORE option of every message protected uh with this context.

So what did we change since uh November? Well, we uh of course took advantage of the feedback we got there. Um, thanks a lot for that. Uh, we extended the length of the uh stand-in KID used to obfuscate the plain value from two to three bytes, and that helps reducing uh the chances of false positive when inspecting recipient contexts uh to consider. Uh, and we also improved the main algorithm, especially at the recipient side, not really in its main steps and rationale but more in terms of more efficient error handling and relation between the steps, um especially for the sake of terminating the algorithm earlier uh if something is off. And the main point that I also mentioned before, that's largely based on feedback from Martina. Thanks a lot for that. Uh, we made it possible uh to obfuscate the KID field if there is a specific agreement on that, uh since the same goal in some use cases is achieved anyway uh but in a more efficient way. Uh, I'll come back to that in a following slide. And we also extended the security considerations.

Uh, yeah, at some point I really needed some new terminology, so I defined these terms to distinguish different types of security context. Um, an ordinary security context is well a vanilla one uh as defined in OSCORE and Group OSCORE, and when using a context of that type, the method defined here is not used at all. Then we have an obfuscating security context that uh is clearly recognizable because it includes the newly defined obfuscation key for deriving the key streams, and when using that context, for sure, uh the Partial IV is encrypted. But then there's a particular subtype of obfuscating security context that I call for now (there will be room for bikeshedding) incognito security context, and if using that in particular, not only the Partial IV is encrypted, but uh the KID field is also obfuscated. And the way to specifically recognize an incognito security context as such um is left as uh local and implementation specific. Uh, so again, the type of specific context has to be agreed uh at establishment time.

Uh, now on when and why not obfuscating the KID. Uh, well, like also discussed with Martina, some use cases are better off without doing that and still achieve the same goal at the end of the day. Uh, think especially of using SCHC for header compression. Uh, that's based on following static compression rules with descriptors uh mapped against different fields in the message, and for the compression of the KID, they typically expect the presence of the KID with a predefined fixed value. And all the descriptors in the rule have to match with the candidate message to compress in order to compress it. So if in such use cases we insist on doing the KID obfuscation like proposed in this document, well that will work, the recipient can correctly process the message, but there will be no compression and we will just achieve the the intended effect in a less efficient way. If we let SCHC compression do its work, the KID field would have been elided altogether and you'd achieve obfuscation by elision, um essentially. But for other more general um use cases instead, KID obfuscation um is the way to go, we argue.

Uh, okay, looking at the actual method here, uh on the sender side, it's first for sure about encrypting the Partial IV; that is going to happen and about that there are really no changes compared to the previous version of the document, so the slide here is only for reference.

But then when we get into the second part, well uh the main update was about making this part not necessarily happen uh only if the security context uses specifically an incognito security context, um then we also obfuscate the KID. And the way according to which that is done is also unchanged uh compared to the previous version uh of the document. Only that when we produce the standing KID to put in the message, as I mentioned before, we um extended its size to be uh of three bytes.

Uh, yeah, on the recipient side, uh it was large about aligning uh with the update we made uh on the sender side. We still want to cover the general case where the recipient is storing uh a mix of contexts of different types, uh and without having um an in-band signaling uh in the messages. So we have to be ready for the general case where the recipient side is also storing ordinary security contexts, and as a first assumption, it thinks that, "Oh, well, maybe this message was not obfuscated at all. Uh, now I'm trying to recover an ordinary security context uh using the regular retrieval procedure described uh in the OSCORE RFC." And actually, it is not going to find one unless it has ordinary security context with the recipient ID of exactly three bytes in size, which is not exactly common. But in principle, it can find one and it can be a false positive, which would lead to to decryption failure. Uh, so if no context is found or uh that false positive decryption fails, the recipient doesn't stop and starts inspecting the obfuscating security context. And it should really start from those that are not incognito security contexts, because focusing on those alone it can apply again the retrieval procedure originally from the OSCORE RFC and hopefully find uh a context. Well, it will hopefully find something and then, consistent with the sender side, uh if it's specifically an incognito security context, there will be a local recomputation of the standing KID, and if it doesn't match what is in the message, this is not the right context, try another one. If there is a match, barring a false positive, um this is the right context. Um, irrespective of the context being incognito or not, it's an obfuscating security context, so there is going to be a restoration of the plain Partial IV, um and finally an AEAD decryption.

Uh, yeah, Group OSCORE was completed already, it is completed now too, we just aligned it with the same updates made uh on the OSCORE algorithm. Uh, the same considerations, spirit and side effects uh remain unchanged; they are here uh just for reference. We added a new subsection about uh a special case that we forgot to include the other time. When using Group OSCORE, this method is not really applicable, I would say, not even relevant uh when specifically producing uh a deterministic request uh for Cacheable OSCORE, uh and in that case, in that request, the the KID and Partial IV field are expected to be very fixed and very deterministic, so there's really um no point anyway. On the security considerations, we added a new subsection discussing specifically the trial decryptions that are possible in general in case of a collision of identifier. Um, we discuss those that can happen here because of this method. As mentioned before, there's at most one in the first phase of the recipient processing um in case there are retrievable ordinary security context with recipient ID of three bytes at least that uh by bad luck matches uh what is seen on the wire, or otherwise, it can happens later on because of a false positive uh with the standing KID. But irrespective of what exactly happened, a failed decryption is a failed decryption, so the message processing must stop and the recipient uh has to update the counters of uh failed decryption when using a decryption key consistent with the key usage limit uh for the used uh decryption algorithm. And then we also added content on security considerations related to uh well possible to not obfuscate the KID field that I mentioned before.

Uh, so as next steps: uh the Group OSCORE part is completed in terms of method, but we have to describe uh side cases, for example, support for the external signature checker. And we need to define the suggested methods that two peers can use uh in OSCORE or in Group OSCORE to agree about using this method or not and with what variant. Uh, we have a proof-of-concept implementation for Californium aligned with the previous version of the document, uh so really obfuscating both fields. It has to be aligned with this version for the sake of possibly omitting the obfuscation of the KID field.

Uh, thanks for the feedback so far. Uh, more feedback and comments are welcome. Thank you.

Carsten Bormann: So, any feedback? Any questions?

Christian Amsüss: Thank you for bringing that up. That was a very, very good point. And and I can say that from a from a protocol design, it wasn't difficult at all to make the change; editorially, it was a bit painful, um especially to ensure that the number of steps remain the same in the same order. I'm sorry.

Marco Tiloca: Good. So it seems we are done with our last item on the agenda. So the next item is any other business.

So we will meet in four weeks for the next CORE interim, in April 22nd, I think.

Marco Tiloca: Yes.

Carsten Bormann: And uh yeah, let's get the bits flowing, let's start preparing interops and uh demonstrating that documents are ready for Working Group Last Call. Uh, right. Thank you.

Marco Tiloca: Thank you all. Thank you very much for your work and contribution. Looking forward to seeing you face-to-face finally in Vienna. Same, very much so. And enjoy Shenzhen as long as you're still there. Yep. Yep, plenty. Thank you. Thank you all. Bye-bye. Thank you all. Bye-bye.