**Session Date/Time:** 20 Jul 2026 07:00

[00:00:05] **Hannes Tschofenig Tschofenig**: How are you? Oh,

[00:00:08] **Elliot Lear**: disastrous. Oh, were you on the United? Yeah. Was gonna No. No.

[00:00:12] **Daniel Rice**: Had a doubt that we asked you in list.

[00:01:13] **Henk Birkholz**: Yeah. And I can wait.

[00:01:18] **Alexeyey Melnikov**: Good good morning, and welcome to Vienna and the first meeting of the week. Our room is fully packed. I'm so shocked considering we're against dispatch. If you really just like dispatch or you really like us, maybe both. I don't know. We'll find out.

[00:01:38] **Henk Birkholz**: Sorry. No problem. That's I should

[00:01:44] **Alexeyey Melnikov**: one second.

[00:01:47] **Henk Birkholz**: I will do the same echo.

[00:01:51] **Alexeyey Melnikov**: So wear chairs. I'm Alexeyey. Henk is sitting next to me in case you haven't seen us yet. And with that, let's get going. Please note well. I hope you're familiar with this. If you haven't, you should familiarize yourself with various procedures governing participation in IETF and good citizen behavior, etcetera, etcetera. So, yeah, this meeting is recorded. If you're on-site, please use on-site tool so that people can add themselves to the queue, and we are being fair to remote participants. If you're using full full tool, you can do that, but make sure that your audio is not echoing like it was for me just a minute ago. Okay. And the slide shows icons for the on-site tool from the agenda. Okay. We need a notetaker.

[00:03:11] **Daniel Rice**: I knew what this was like. You

[00:03:13] **Alexeyey Melnikov**: just just didn't follow my advice just now.

[00:03:17] **Hannes Tschofenig Tschofenig**: I just

[00:03:17] **Alexeyey Melnikov**: That's amazing. I just told you this is impossible. The tool doesn't offer it.

[00:03:23] **Henk Birkholz**: That's the tool. Right? Yes.

[00:03:26] **Alexeyey Melnikov**: It's all always somebody else's fault, of course. Right. We have a request for some bashing of the agenda because Elliot actually needs to to be in dispatch. So Mhmm. If people don't mind, we'll let him go first, and then we'll just adjust the thing accordingly. So can we have a note taker, just the major points? That would be great. Thank you. You know where to go. Right? Okay. I just started the template. Add your name and just the main points or the main discussion points if no need to copy the slides and etcetera. So k. Thank you. Right. Elliot, coming in. So you're going to talk about licensing first and then MUD extensions. Is that how you want to do it? Sure. I mean, it's up to you. Like, I don't mind.

[00:04:32] **Elliot Lear**: That's fine. That's good.

[00:04:35] **Alexeyey Melnikov**: Official business first and then okay. So one second. I might need to refresh.

[00:04:46] **Henk Birkholz**: Just while Alexey is looking for the other inputs, is there any other business and slide pushing in the room just as a formal check? Yes? Mike, sorry. You have to be on the record. I'm sorry.

[00:05:04] **Daniel Rice**: It's brain not fully activated yet. But, yeah, I'll be sending an email

[00:05:08] **Henk Birkholz**: Name, please.

[00:05:09] **Daniel Rice**: This is Daniel from CableLabs speaking. I'll be sending an email out after the session today, but I am planning to run a demonstration of the implementation of the protocol and etcetera that I'll be discussing today. So if anybody's interested in joining, I haven't set up, like, a side meeting or anything yet.

[00:05:28] **Henk Birkholz**: Okay. They can do this in the any other business after the meeting. Wonderful. Thank you so much. Sorry again? Speak real loud once.

[00:05:37] **Daniel Rice**: Testing. Testing.

[00:05:38] **Henk Birkholz**: Oh, that's not good. Yes. Thank you. I can hear myself, but maybe I should hear you also.

[00:05:46] **Elliot Lear**: Testing. Oh, wonderful.

[00:05:51] **Hannes Tschofenig Tschofenig**: You may notice the the engineer in the room was

[00:05:54] **Henk Birkholz**: Perfect timing, Elliot. Take it away. Do

[00:06:00] **Elliot Lear**: you want do you want

[00:06:00] **Alexeyey Melnikov**: to use clicker, or do you want

[00:06:02] **Henk Birkholz**: Which does not work yet. You have to assign advance.

[00:06:05] **Elliot Lear**: It's fine. I don't have

[00:06:06] **Henk Birkholz**: any It's just post.

[00:06:07] **Elliot Lear**: This one this one's easy. So Carsten hasn't even seen these slides because I created them ten minutes ago. This document's been around, and it's been languishing a little bit. It the purpose of the document what Carsten noted was that some people might have difficulty actually sharing my files and sharing other, you know, YANG based serializations because there was no copyright statement. And in some jurors in many jurisdictions, if there's no copyright statement, that means you can't share. So we created a very simple way to share a copyright statement. Mostly, should be making these MUD files, in particular, freely available. But we allow for flexibility if you want to get really crazy about how you want to share this stuff. How about it? You can use free text, SPDX tags. Those are sort of the two choices. It was initially targeted for MUD, but, you know, if you serialize and save other YANG based documents, there's no reason you couldn't use it for for this as well. Next slide. Elliot, is your mic off? Is my mic off? Oh, that's a good question. It was?

[00:07:23] **Henk Birkholz**: No. My I can't hear you still.

[00:07:25] **Elliot Lear**: You can't hear me still. Okay. So I'll try and eat the mic a little bit. Alright. This document has actually gone through many revisions but few changes. So the last one, though, went through changes addressing the YANG re the YANG doctor's review. And so there was a slight clarification on the on the choices available. And there was a comment from the YANG doctors that we shouldn't be using shortened versions of like, ol was a bad choice for a YANG name. So we expanded to owner-license ownership owner-license. And we we clarify that you need to have at least one license if you're going to use this. Otherwise, why would you? And then the only other change that we made was we used the standard YANG security considerations, and that's it. This document is really sort of stupid simple, and we should just move forward and do a working group last call k. Now that we're done. So can we do that?

[00:08:35] **Alexeyey Melnikov**: I don't see why not. Sounds like we are if we're ready. Well, we we can talk, but I'm I'm sure. At the moment, we don't have any documents. Well, now, technically, we have one document in the last call, but and I personally don't like to run too many in parallel, but I think we can do it very shortly.

[00:08:55] **Elliot Lear**: Okay. Alright.

[00:08:56] **Henk Birkholz**: But we will have the official call on the list. We'll give you two weeks and then so on and so on.

[00:09:00] **Elliot Lear**: Yeah. The only the only thing I would ask is read the document. It doesn't take toolong. There's not much there.

[00:09:09] **Alexeyey Melnikov**: Alright. Do people have preferences if August is a good time to do dolost calls? I kind of would like to have some reviews even if they just say, oh, it's fine.

[00:09:21] **Elliot Lear**: Yeah. So Do it this week? Hey. So can I get some people, like, some some who who might just read this document while they're you're being bored in another working group meeting? And it it's literally this long and just say send a note back to IoT ops saying, yeah. Okay. Can one or two hands go

[00:09:40] **Alexeyey Melnikov**: up, please?

[00:09:41] **Jim Mosley**: Okay. Jim was gonna say yes.

[00:09:43] **Elliot Lear**: Oh, thank you, Jim. Excellent. Good. Because I chat all over his document. Alright. That's it. Next?

[00:09:52] **Henk Birkholz**: Thank you so much. And just as a final words, you don't have to check the 400 plus licenses. It's about the representation. It's just just to scope your review. Okay.

[00:10:05] **Elliot Lear**: So so next, we have MUD extras. Alright. So MUD has been around now for a good number of years. Its adoption is a little on the low side to put it mildly, but it has there's some some new life being breathed into it for various reasons. Next slide.

[00:10:21] **Alexeyey Melnikov**: Second.

[00:10:25] **Elliot Lear**: Right. So, why? Well, thank you, Mirai. Now pretty much anybody can be attacked very quickly for you know? And and the IoT manufacturers, like, the worst people to be able to actually keep their their their products up to date. It's you know, we we got products that are that are stuck in the field and never updated. Well, that means the network role becomes even more important in terms of their protection. So that's that's the majority the the main reason that we're seeing a

[00:10:59] **Daniel Rice**: little bit of

[00:11:00] **Elliot Lear**: of impetus for for some sort of profiling protection. And, MUD, having been around a while, a couple of people have noticed a couple of issues, and there's some opportunities to do some cleanup. So this is basically an update to 8520 at the start of an update to 8520. This is my opportunity to to say that this is your opportunity to say, well, what is good about manufacturer usage descriptions? What is bad about it? What needs to change? I really would prefer that the format the document be an or something like that, whatever you like. But now is a good time to say what to to reflect and say, what has worked and what hasn't worked and what would improve adoption, and we can start to answer some of those questions. Next slide. So what MUD seems to get right, I think the abstract the abstractions actually seem to do a pretty good job in covering profile. They're pretty you know, it's it's pretty it's pretty easy now to generate these things, and I'll I'll talk about that in a minute. Next slide. So this is an eye chart. I'm not sure if you can see this, but they're basically four things that immediately I we we noticed through some amount of experience, which is initially I said, don't use IP addresses in MUD files. Why wouldn't you? Well, because IP addresses change and MUD files should try to be stable as much as possible. And in reality, a lot of IoT devices do hard code IP addresses into in in their firmware and some place else. And so the point of a MUD file, the point of the profile is to reflect what the device needs. And if it needs to have IP addresses, then we have the YANG MUDel for that. In fact, MUD is based on that YANG MUDel, so there's no reason not to have those in the file itself. However, there are some caveats. Like, you certainly don't wanna put local, you know, IP addresses, and they're like network 10 or something like that. And, you know, IP addresses do make things fragile. So I'm not recommending it. I'm just saying this is happening. The second is multicast, and this is a little bit weirder. You know, you can stick since you have this IP address access to this MUDel, you can stick multicast addresses in there just like anything else. But there's in in some cases, devices expect the multicast to stay on the local wire, and in some cases, they think that, well, maybe this needs to propagate. So these multicast as a way tolimit the scope of their communications one way or the other. But if things are expected to go beyond the local wire, the deployment needs to know that because deployments often will not allow multicast go beyond the local wire. They don't set up multicast routing in many cases. So this is just something it's an informational mark to say, yeah. That might be the case with this device. The question really is and this is an interesting point for this this particular one is, is this something that the manufacturer can actually spot well? It's an open question. Directed broadcasts are things we hate. Okay? I hate directed broadcast because you have to configure them all over the place. They're they're subject to attack, but people use them. Why? Because the if you are a controller and you wanna hit a bunch of devices at once and you don't have multicast, you have very limited choices and directed broadcast is one of them. I hate this. I'm not recommending it, but it's done. So that's that's one of the extensions that we placed into this this new draft. We being me, but I'll talk about the we part in a moment. Normal broadcast are easy. Here, what we're saying is we just wanna clarify. You gotta allow normal broadcasts in terms of you know, you shouldn't have to put that in a MUD file, right, that that that you that you're gonna handle normal broadcast, but we clarify that text. So the point of this document actually is clarifications, some extensions, and it's an opportunity for everybody to jump in to the pool and say, I want this. I want that. We talk about it in in this room. Right? And if so Michael Richardson, who's not in the room, has already said, oh, I want this this thing here for some work that he and Henk are doing. I think, actually, Karsten, from an SDF perspective, one of the things you might wanna consider is is putting in a URL to to receive enough SDF MUDel. You know, it's a kitchen sink. Feel free to now is a good time to get those ideas out. And what I'm what I'm what I'm gonna suggest for a way forward for this document is we peep first of all, people read it. I will not be present in San Francisco in person, but I will be present on the you know, virtually. Around San Francisco, what I'm what I'm gonna suggest is we adopt it, but we take some time to sort of go through what we think needs to change, what we think we like. Mhmm. And and then we just go from there. And now it would be a good time on the list to have a refresher about what these descriptions describe, what their purpose is. And with that, my only ask of this group is think about you know, go back, read eighty five twenty, read this document, give it some thought, and let's discuss on this. Okay?

[00:16:55] **Alexeyey Melnikov**: I'm being super optimistic, but do we have to wait till San Francisco?

[00:17:00] **Elliot Lear**: We absolutely don't have to wait till San Francisco. People wanna adopt beforehand, but I'm I I I don't I also feel like this is the first time you've seen the document.

[00:17:09] **Alexeyey Melnikov**: Yeah.

[00:17:10] **Elliot Lear**: So That's fair. You know? But but now is a really good time for people to think, I need this or I need that or this will make it useful. And we should be a little critical. Like, people should think about that multicast one. That's a that one is still a question in my

[00:17:24] **Jim Mosley**: own head.

[00:17:24] **Henk Birkholz**: Mhmm.

[00:17:25] **Elliot Lear**: Right? And we can dump stuff out. We can put stuff in and dump stuff out. We don't have to rush this. It's a it's a good opportunity for people to to take a look. Okay? And now when I said me, I really do mean we. So at the end of the day where it says author Elliot Leer, I'd like that personally to change to editor or have multiple authors so that we you know, there's plenty of room in the pool for this one, and the water is perfect. And that's it.

[00:17:53] **Henk Birkholz**: Thanks, Elliot. Yeah. As a as a chair not going to the mic. So I'm at the mic now. So chair head off. I think clarification on how to compose the most simple MUD file for you, and your convenience is nice. Not everybody is super stoked about having go through YANG and then realizing, oh, you don't have to do the XML and then and then going down the ladder. So I think clarification where your sweet spot is, how to create a MUD file and some guidance on that is, like, useful.

[00:18:28] **Elliot Lear**: The easiest way to create a MUD file actually is to go to mudmaker.org, drag a bunch of PCAP files over onto the the the little diagram, and it will do the rules generation for you. Now you have to go and look it over and see if you like what it generated and see if it's covering all your use cases. And you wanna make sure that you've exercised the device such that it's using its capabilities. So you're getting everything in the p cap file. But you do that. Life is pretty good. And then you just fill out the little informational section, and away you go. And I'll put more information about that on the list. Thank

[00:19:03] **Henk Birkholz**: you.

[00:19:04] **Elliot Lear**: Because we don't wanna worry about, like, squiggles and and what have you, the, you know, the actual Alright.

[00:19:11] **Alexeyey Melnikov**: Thank you.

[00:19:12] **Elliot Lear**: Thank you.

[00:19:20] **Alexeyey Melnikov**: K. So we're at twenty minutes, and that's, I think, fine.

[00:19:24] **Henk Birkholz**: We are absolutely fine. Jim is fine.

[00:19:30] **Alexeyey Melnikov**: We can okay. Okay.

[00:19:32] **Henk Birkholz**: Now with the spontaneous agenda bash, next up would be Jim with the summary. And he seems to be alright and okay about this. Take it away.

[00:19:50] **Jim Mosley**: Thanks, Jess. Jim Mosley speaking really for Brendan Moran here. Brendan's created the draft summary of security enabled technologies for IT devices. I was asked to take a look and do

[00:20:03] **Carsten Bormann**: a bit of a review.

[00:20:06] **Jim Mosley**: Can we have the next one clicker?

[00:20:08] **Alexeyey Melnikov**: Yeah. The

[00:20:08] **Henk Birkholz**: clicker is not let us Is it normally you would do it. Okay.

[00:20:11] **Alexeyey Melnikov**: I think let me let's try it. You

[00:20:14] **Hannes Tschofenig Tschofenig**: want Okay.

[00:20:15] **Henk Birkholz**: We have the minutes. I know we understand.

[00:20:17] **Jim Mosley**: Just using my AI assistant. Done. Yeah.

[00:20:21] **Alexeyey Melnikov**: I'm not sure controlling the slides. Okay. So try it now.

[00:20:25] **Henk Birkholz**: Click. No. Click.

[00:20:30] **Hannes Tschofenig Tschofenig**: It's not done. It's turned on.

[00:20:33] **Jim Mosley**: My AI assistant has had a hallucination.

[00:20:37] **Henk Birkholz**: I'm pretty sure

[00:20:37] **Hannes Tschofenig Tschofenig**: I'm clicking things. When they should switch aside. They have

[00:20:40] **Henk Birkholz**: to No. There's a it's it's associated. Yes.

[00:20:42] **Carsten Bormann**: Yeah. Yeah.

[00:20:46] **Henk Birkholz**: I can press this button for

[00:20:47] **Alexeyey Melnikov**: a longer time. No. Hold on.

[00:20:49] **Carsten Bormann**: This one. This

[00:20:52] **Alexeyey Melnikov**: one. It is on. How many engineers it takes? And

[00:20:57] **Henk Birkholz**: and did I try to put do it off and on again? It's blinking again. Yeah. And there we go.

[00:21:06] **Alexeyey Melnikov**: I see

[00:21:08] **Hannes Tschofenig Tschofenig**: a pattern here. Yeah. Microfronts.

[00:21:12] **Daniel Rice**: That's it.

[00:21:13] **Jim Mosley**: Okay. I

[00:21:14] **Henk Birkholz**: will have something for you later.

[00:21:15] **Jim Mosley**: We won't mention we won't mention Pepcak. Alright. So, yes, this is Brendan's security summary. I was asked to take a look at this. It has actually expired. That's the the status of it at the moment. For those that are not aware or are new here, let me look at the sort of summary of this. This this memo serves as an entry point to detail which technologies are available for use in IoT networks and to enable IoT designers to discover technologies that may solve their problems. And I think it's in the intro that it talks about being based on some security baselines. One is ENISA's baseline security recommendations for IoT in the context of CNI. The other one is ETSI's cybersecurity for consumer Internet of Things. And the last one is NIST IoT device cybersecurity capability. So the the the context of this is that the draft is based on those three things. In the abstract, apart from the the thing that I read, it also talks about developing a threat MUDel from the combination of the security requirements of these three documents. The threat MUDel isn't in the draft. So assuming we progress this in some form, we either need to drop that because the security MUDel is actually in those baseline documents and then the requirements are derived from that and then put into the draft, which would seem to be the a reasonable way to proceed because it's based on those documents, or we'd need to actually add a add a threat MUDel. So if we look at the security requirements, we we we'd want to examine a few things assuming we we progress. What about other relevant standards? I mentioned three. Are there any others that we need to do? A colleague told me that NIST may be revising some

[00:23:20] **Martin Lenders**: Mhmm.

[00:23:20] **Jim Mosley**: Advice to do with with IoT stuff. I've not had a chance tolook at that yet, but that's an example of where standards will will change. When when we look at these, if there's a conflict between, say, these three standards or any others, which one do we select? The one that is the least stringent or the one that's the most stringent? Or do they apply to different devices in different circumstances? Like, is my smart TV as critical as a health care device? That kind of thing. So so we'll have to make some sort of decisions around that really. There's a mapping of of requirements. And and again, if that's a snapshot in time, how will we deal with that is is, I guess, a challenge. And how do we keep it current was a thought. Carsten, do you have a question?

[00:24:16] **Carsten Bormann**: Actually, I have a suggestion. Yeah. The the landscape of of those documents out there is going to change all the time. Yes. We will never complete this document if we try to be comprehensive. Right. So I think we should, right in the outset, say, we are looking at these three documents, and this is our summary of these three documents. And then we can have another document later that looks at two more of them. But try trying to keep this up to date with the whole landscape is not going

[00:24:44] **Henk Birkholz**: to work, I think.

[00:24:46] **Jim Mosley**: Thanks. I mean, I personally, I would agree having looked at it. I'm definitely not the expert in the room here, but that would seem to be reasonable.

[00:24:53] **Alexeyey Melnikov**: I think in private discussions, there was also words like, you know, that if we had a concept of living standards in ITF, then that would have been one of those. So, yeah, maybe another way we can do is we keep updating it. At some point, we say, let's have a snapshot. Let's publish RFC. And then if there is more after that, then we'll do it best. I don't know. That's I suppose that's the closest. It's more kind of a great process than than living standards if we had them, but that's kind of the next best thing. Alright.

[00:25:27] **Jim Mosley**: So I did wonder if we could split it into sections or into different drafts. So we might have a draft that that's to do with, say, access requirements and and and break it down that way.

[00:25:41] **Christian Amsüss**: It might

[00:25:41] **Jim Mosley**: be just to keep it up to date.

[00:25:43] **Hannes Tschofenig Tschofenig**: I think so the document initially was written pre AI days in in some form. Nowadays, it's quite easy to produce a summary of three documents. So the question is, is the goal of that write up still the same today than we had, let's say, five years or whenever it was done? Why do we have a write up of three documents, a summary? That strikes me as not ideal. And having said that, like, there are a produced with a student a summary of 1,000 of those IoT recommendation documents because there are so many. So we picked those three probably because they are more interesting, but I doubt that even people read these three. So so I think we as you did with the earlier slide on the threat MUDel, we might want to rethink on what we are we're trying to accomplish here. Now since this was written, we also have the cyber resiliency act, and which again places different requirements. And I'm I'm as we are speaking, people are sort of looking at this whole topic again and produce new implementation guidance, etcetera, etcetera. So there's

[00:26:57] **Jim Mosley**: I I I think the the objective of this as I read it was not so much that it's a summary of the requirements in its intent. The outcome is is meant to be that it gives manufacturers guidance on how to meet those requirements. So so that's the intent that we're aiming for. So assuming that intent is still the same, it's what is the best way to achieve the outcome, not what is the best way to get the summary if you see what I mean. That that's a that's a step away.

[00:27:24] **Hannes Tschofenig Tschofenig**: And do we still agree that that's the the side of everything to do? I don't know.

[00:27:34] **Alexeyey Melnikov**: Sorry. I probably will take my chest hat off for this. I think it's a road map. So having some starting point is for people, like, if you have these sort of requirements and these sort of threat MUDels, if we go this way, then, you know, this is go read these documents and look at these RFCs or other stuff outside of ITF, which is working together with.

[00:27:57] **Jim Mosley**: Okay. So maybe then if I move on to onto here, I I think we've got the different options which are obviously progressing as it is effectively. So we've got a draft at the moment. We definitely need some additional authors, volunteers for it. I went back through some history of this. I'm sure that there are people that know this better than me here. There was a call for more volunteers at IETF one one eight. I don't know that that happened. I'm assuming it didn't because I can only see one author on there. So we would need a more collective effort.

[00:28:33] **Alexeyey Melnikov**: I think we did at the meetings, and there were no volunteers at the meeting. So but hopefully, situation has changed. So

[00:28:42] **Jim Mosley**: Yeah. So that that's that's something that that if we wanna get some impetus in this, we definitely need to do. One option yeah. So progressive drafted it is one option is to break it into maybe smaller drafts addressing different areas. You know, do we have something that talks about access control for IoT devices or even smaller like password management or whatever? Do we have something that's that's logging for IoT and have that as one draft? So break it into its constituent parts is is an option. And perhaps different people could could attack those. So the the the the other thing, obviously, to do would be to keep it as a reference. And so to your point about collecting the different information from things like ETSI, NIST, etcetera. You could just keep it as a reference document. So change the objective almost to say, here's a summary of the things. The problem that I saw with that is then, do you update all the drafts that talk about the different aspects of security to point at this? That's perhaps a lot of drafts to update and do the biz for or whatever's necessary. So that didn't seem to fit the bill either. Of course, there is another alternative, which is not progressive. I'd be remiss if I didn't mention it, but it seems to me to be a a useful thing to progress. So Right. So that's it. Any any more comments to just discussion points? Any suggestions of the way forward?

[00:30:09] **Alexeyey Melnikov**: Can can we to

[00:30:11] **Jim Mosley**: initiate discussion as much as anything because I'm I'm not the the author of this.

[00:30:16] **Alexeyey Melnikov**: I don't want to manipulate the room, but I have more input. So I think you got the answer that we don't want to publish it as in the current state. So it's not

[00:30:26] **Henk Birkholz**: Okay.

[00:30:27] **Alexeyey Melnikov**: At least, you know, the feedback we just got from the mic from Hannes Tschofenig and Carson. So in regards to breaking it up into multiple documents, in a way, I think it's editorial issue. You can still have, you know, several authors on a single document, and they just have responsible for subsections. So in a way, I don't think it matters how we structure it. We can decide, you know, if it becomes too big to split that up, but I wouldn't make it a requirements on editing. It's kind of a tutorial decision, so we, you know, we want to document on x. It might end up being couple or just one. That's that's fine. Doesn't matter.

[00:31:10] **Jim Mosley**: Okay. So assuming we're gonna progress it progress it as is and then see how long that gets. Yeah. Yeah. Okay. And then split up accordingly. Okay. Yeah. So so how do we progress this? Are there people that are willing tolook at it and move it forward? Shall I put a call on the IoT ops list and ask, is that is that the best way to proceed? I can see one not I

[00:31:38] **Alexeyey Melnikov**: feel some people are just they're just restricting themselves from committing to this great project and, you know, like, come on, people. Save now. I think

[00:31:49] **Jim Mosley**: people are enthusiastic because they're not in dispatch. Right? So it must be ready to go. Okay. Let me let me take action then to put something on the list and see if we can get some some impetus behind this. Alright. Thank you very much.

[00:32:02] **Alexeyey Melnikov**: Thank you very much.

[00:32:04] **Jim Mosley**: Yes.

[00:32:11] **Alexeyey Melnikov**: Sorry. I need to take away the clicker and then

[00:32:16] **Henk Birkholz**: I also took away the clicker.

[00:32:20] **Alexeyey Melnikov**: And then I need to change documents

[00:32:23] **Henk Birkholz**: now. Oh, prematurely, I think. So

[00:32:39] **Alexeyey Melnikov**: DNS security and privacy guidelines. Yes?

[00:32:42] **Hannes Tschofenig Tschofenig**: Yes. Yep.

[00:32:45] **Alexeyey Melnikov**: Exactly. And now

[00:32:48] **Jim Mosley**: Alright. It's me again. Talks will continue until agreement is given. So IoT IoT DNS security and privacy guidelines, We have this as a a working group last call. Do forgive migrants of the process. I've not been in this situation before. So seeking feedback on on this. This is as a recap, a guidance for IoT manufacturers about implementation of DNS stub resolvers on IoT devices. This is based on research by UCL and Inria, a very large IoT lab, finding things like source port transaction ID randomization isn't sufficient, and a whole number of the things that are referenced in the draft. And it also covers the management of zones used for used for the purposes of device management. The nature of DNS is obviously that you've got a stub resolver, a resolver that goes out and finds answers on behalf of those devices, and authoritative servers and the system works across the three of them. So we try tolook at it across those three elements of of DNS resolution in terms of mitigation of the risk. We've had an early DNS sorry. Please give me sec. We've had an early DNS director review of dash o one version. Actually, we're on dash o four now, and the verdict there was was almost ready, which is useful. So just to do a bit of recap through a couple of revisions and then ask for ask for feedback. In the version three, did we incorporated that feedback from the DNS directorate, and we'd like to thank Patrick for for that review. We did some further changes to separate out really some guidance for network operators that are that are looking after those resolvers on networks where IoT devices are deployed. Obviously, there's quite a variety of networks there deployed on, some of which are private organizations who have perhaps stricter security requirements and and and want tolock things down more. Obviously, there's a lot of home IoT devices where that kind of security is not in place. So one of the feedbacks was to make it make it clear because the document is primarily aimed at IoT device manufacturers. But because of the nature of DNS and and wanting to mitigate threats, you do want to provide some advice to network operators. And we did a lot of work on the section on DNSSEC. So the latest version we published a few weeks ago. We took onboard some feedback, and we've we we we've really tweaked some of these sections. Probably the biggest thing that I think remains is is tweaking on DNSSEC stuff that I'll come on to. But we've incorporated some some feedback there. Elliot's disappeared and has got a load of questions, some of which I've got on here. So this is really the the stuff that I wanted to discuss today. We've we've got a general format in each section of sort of problem statement or really finding from research. And it it it sort of says what the what the risk is, then we've got a a mitigation in there. One of the feedback points specifically from Elliot was to actually reference that. So we'll we'll be improving the referencing. There's an academic paper which outlines the the risks. We'd we'd reference that in the introductory section, assuming that then people would know that the problem statement effectively comes from that paper that we'd already referenced at the beginning. But we'll tie those references more directly into each of the sections. We didn't know if we wanted to improve device improve advice on avoiding fingerprinting in the document. We do mention it in a couple of places, and it is mentioned in one specific area around mitigations of that. We didn't know if we should if if we should improve that. One of the things that was suggested that was as well as the sections we've got, we actually maybe have a table of threats and mitigations as a kind of summary. If that's good from a kind of readability point of view, we could do that and then reference the sections. We did have a discussion amongst the the authors, and we felt that creating turning all the sections into one large table would be not so good in terms of readability that that we could do that. I know you're all enthusiastic, so do feel free to go to the mic if you've got any particular comments on any of these. So, yeah, DNSSEC is something that we've we've changed quite a bit during the iterations of these drafts. One of the pieces of advice was to talk about the most likely scenario, which is IoT devices are not gonna perform DNSSEC validation themselves. Indeed, most clients don't. It it is a possibility, but your laptops here are not performing DNSSEC validation. They're leaving it to the resolvers. And and that's obviously gonna be the most likely scenario. We we we clarified in the most recent version. I I think about the the resource usage of of DNSSEC or encrypted DNS somewhere. So that's obviously an issue in IoT devices. But it is theoretically possible that an IoT device could perform DNSSEC validation itself, and there were some comments on that. Again, I'd I'd ask the room if that's something we want to progress or there is even an option to say, sort of, you know, here be dragons. We don't want to discuss that in this draft because we don't believe IoT devices will perform DNSSEC validation at which point we could we could drop that bit. So for those that love DNSSEC, and I again, I can feel the enthusiasm in the room, Have a look at that and and and see if you've got any comments on that. We want to add why hard coding resolvers is bad. It's probably obvious to us. But as Elliot mentioned earlier, you know, hard coding IP addresses isn't a great idea, and it might be quite operationally bad if if the devices that have been found that use Google's open DNS resolver are not able to reach it. Well, can they even operate those those kind of issues come in? So it it seems obvious, but but we should probably state that. We've gotta sort out some must should wording in a particular section on on randomization. But we did have a comment about entropy, and we didn't want to get as far as talking about the ways that entropy might be provided in by IoT devices. So we've stopped there, but if you've got any particular feelings on that, then then let us know. Mhmm. And a note that we need to to tell manufacturers where to publish management domains without MUD. The idea for network operators is that in construct more constrained environments where security is more of a concern, that they could restrict DNS queries to management domains only. And one obvious place to publish those would be MUD files, which we reference in the draft. But they could simply publish them on the website or something like that. But I wondered if we should provide some guidance to that. I didn't I didn't want to get into advising manufacturers of devices how to to publish domains. They should simply, I guess, reference in some documentation for that device where that information's found. But if we need to provide some more guidance, then then let me know there. I think, Carsten, you maybe got a question?

[00:41:08] **Carsten Bormann**: When you're done with your list

[00:41:10] **Jim Mosley**: Okay. I'm at the bottom.

[00:41:12] **Carsten Bormann**: So please. Okay. Custom moment. So the the elephant in the room here, of course, is RFC 9953 because that has been written to solve many of the problems here. I mean, it in many cases, it doesn't solve them. It just doesn't create them in the first place. And it probably would be a good idea to to mention this as one of the the ways we have to to just not have a number of problems that that we're having with existing transport and and security solutions for for DNS. And there are several people in this room who know what 9953 is, and I

[00:41:57] **Alexeyey Melnikov**: I have to Google.

[00:41:58] **Carsten Bormann**: Give the microphone to one of the

[00:42:01] **Martin Lenders**: Yes. So I think some of the things that are not addressed in this draft might be addressed in my talk that I give after your talk.

[00:42:08] **Jim Mosley**: So I'm looking forward to us to see some slides this morning.

[00:42:11] **Martin Lenders**: And so, yeah, maybe we can then go into CoAPeration. I mean, I have a question on that at the end of my presentation, so maybe we postpone this discussion to then.

[00:42:21] **Jim Mosley**: Yeah. No. That would be that would be great. Thank you. Thank you, Carson. Okay. A couple of nits we need to we need to bash out. So that's that's pretty trivial. I'll I'll skip over those. Yeah. And and that's my lot, really. Any other questions directly now? I know everybody's read the draft this morning clearly over breakfast and and has some comments. But assuming you haven't, could you have a look, please? Could you provide comments on the list? And we as authors can review, respond, etcetera, and try and progress this. Going once, twice, three times. Thank you very much.

[00:43:10] **Alexeyey Melnikov**: Okay.

[00:43:13] **Henk Birkholz**: Second.

[00:43:22] **Alexeyey Melnikov**: Take away the clicker.

[00:43:25] **Henk Birkholz**: Change slides. You can have this already.

[00:43:44] **Alexeyey Melnikov**: That's the right one. Yeah?

[00:43:46] **Henk Birkholz**: Yes. K.

[00:43:48] **Alexeyey Melnikov**: And you want clicker?

[00:43:51] **Henk Birkholz**: No. One sec.

[00:43:54] **Martin Lenders**: Yeah. Yeah. Now it works. Okay. Yeah. Hello. I'm Martin Lenders, and I will talk about DNS privacy enhancement for the constrained IoT, DNS over CoAP, SCHC and Onion CoAP. This is a talk that is a little bit based on a talk that I gave two weeks ago at Euro SMP. It was originally intended to be in T2TRG, but since they are doing a special feature basically this week, I kindly asked to do it at IoTops. So if you're wondering why this is a more scientific talk, that's the reason why. So I first will give an introduction and basically give our motivation, then describe our threat MUDel and our method of evaluation, and then give our evaluation results. And then basically the thing that is probably most interesting to you all, the protocol recommendation that we drew from our evaluation results and what we can further improve. So our original motivation to do name resolution in the IoT, but and there we have the problem that DNS is clear text, so an eavesdropper can listen in on that. And the typical countermeasure you do for that is to encrypt the name resolution. But when we looked at existing solutions like DNS over HTTPS and DNS over TLS, even DNS over QUIC and even DNS over DTLS, we found that they all didn't work for the constrained use case. So TCP is always a problem with resource constraints. Same goes for TLS over UDP. And with DNS over DTLS, there is no segmentation. So if you have fragmentation on the lower layer, it alsoleads to problem. So there's a

[00:45:39] **Hannes Tschofenig Tschofenig**: new

[00:45:39] **Martin Lenders**: proposal, RFC 9953, DNS over CoAP, which provides encrypted communication for the constrained IoT using Datagram, transport layer security and object security, so OSCORERE. And it also comes with blockwise transfer. So we have a lightweight segmentation mechanism that puts it into blocks of equal length. And we also have onward caching to mitigate a linked layer packet loss. So but when you look at the typical threat MUDel that an attacker wants to distinguish DNS from data traffic, we face a problem that the typical mitigation techniques you use with DNS over HTTPS, for example, don't work because with EDNS(0) padding, there's a problem that the draft- the RFC for that actually recommends padding lengths of a multiple of 128 bytes, which is already larger than some of the PDUs we have in the constrained IoT. And artificial delays, you can do them, but you already have quite high latencies and low data rates in the constrained IoT, so you might choose not to. So we actually wanted to explore the benefits of the constrained use cases to increase obfuscation. And to that end, we analyze what header fields are actually leaking and identify possible countermeasures. So the benefits we identified for the constrained use case are actually the blockwise transfer because, as said, already it already splits the packets into equal lengths. So it basically does something similar to what padding does. And the other way thing is that we have often header compression to adapt for the link layer. In this case, we looked at SCHC to alight actually headers and alight as much headers as possible. So for our method, we looked at we first collected some data from the HTTP archive and Quad nine, then ran them through two ninety six traffic scenarios. Then on the traffic on these traffic traces we got from that, did some machine learning analysis with five fold cross validation and permutation importance is to do our actual head of field analysis. So what were these two ninety six scenarios? There we have this nice table in our Euro S and P paper, which basically tells you that we looked at different link layers. So the unconstrained link layer, like Ethernet, and constrained link layer using SIC, where we use three variants. We looked at five protocols, DNS over HTTPS, DNS over CoAP in unencrypted form, DNS over CoAP over DTLS or CoAPs, DNS over plain OS score, and then also over onion OS score, used blockwise transfer with ten twenty four bytes and 64 bytes and then looked also at four d n network setups, which are d one, d two, d p one, and p two. So, basically, that means that we first looked at a setup where we directly communicate with the DNS and data server, which is basically on the same server. That's a rare setup, of course, but we wanted tolook at it so we can say how that looks in our final evaluation. Then the usually approach you would have that you have a split DNS and a split and a separate data server. And then also with p one and p two, how this looks like if you communicate through a proxy. And if you're wondering what onion OS score is or onion CoAP, there is a draft by Christian and Marco in and Rickard also in T2TRG, which basically is onion routing for CoAP. And you actually have some nice OSCORE shells. Yeah. We alsolooked at different data formats and different DNS formats. So JSON and CBOR, I guess everyone should know. DNS is basically the application DNS message format you see in our C8484. And DNS CBOR is for DNS message format we currently are discussing in the CBOR working group, which is which provides a more concise way to communicate DNS messages. So now what are these numbers meaning? So basically, says one, there's just one scenario. It says two, in this case, it's unencrypted CoAP and CoAPs. It's for the OSCORERE, it's Onion OSCORERE and OSCORERE. And the three variants of SIC we are looking at are split rules, which is basically we have one rule per server, so one for the DNS server and one for the data server. Minimum rules is that we have one rule for both of them. And if there is a difference, we do either mapping or use the least significant bytes, whatever is suitable in the rules there. And then we have peer based rules, which are basically that we use the that we have one rule set per server. So we combine the link layer addresses and assume that they are somewhat randomized and coordinated between the devices so that you have one device ID and you basically have rule one both for the DNS server and the data server. So you can basically have a header that looks identical but goes to different points in the network. So if you then do machine learning analysis, you, of course, need a feature vector. Usually you take something like the packet lengths, the time difference between different packets or something like that. But since we are comparing full IPv6 packets versus SCHC packets, we said, Okay, that's somewhat comparing apples to oranges. So we looked actually at the whole packet completely and fed the machine learning algorithms with that, which we then call basically the binary vector. So we translated each byte of the packet into an eight dimensional vector, concatenated them to have a very large vector, and then paired the vectors with trailing zeros trailing twos and do man max normalization to get to the input vector again. And then did five fold cross validations for different machine learning algorithms. We didn't specifically look into deep learning here because we wanted to keep it somewhat simple and also wanted to have some explainability of the results. So in the end, we decided for random forest because it was best suitable for our approach and then did permutation importances with that. So for those who not know anything about machine learning, what is permutation importances? So basically you a feature you give an input vector based on all the feature vectors of the scenario and then take one column I in evaluation step I and shuffle it. And if you have a change in accuracy, then that means that this feature or this column, in this case the split, is important for the overall classifier. And if there's a very large change in accuracy, it actually means that the feature is very important. So with this bit information, we then did a header field analysis, which basically means we mapped the bits to the original header fields in the packet. And could then give some insights into what what headers are actually important. And, yeah, from the evaluation results, I guess Jim will not be that surprised about these results because, basically the first leak we found is the destination information. So basically IP addresses, ports, which make the data and DNS traffic distinguishable. So here we have an example of a very important IPv6 address. But what surprised us actually is also if the data is unencrypted. So here we have unencrypted CoAP in a D2 scenario. Even there, the destination information is the most important information. In this case, it's the IP address and the URI host. And even if you compress it down to a single bit with a minimal rule set, here you see again the IP address and the URI host, what's leaking the information. The other thing is also the transaction IDs or message IDs with CoAP or token IDs or sequence numbers with DTLS because they are all an alternating pattern. If you don't randomize them, they are very important as well. We have this also with DNS over HTTPS that the TCP sequence number is creating this leak. So our first solution is, of course, to equalize the message length using small block sizes. So we here compare block size ten twenty four and block size 64 in violet for overall scenarios with the violin plot. So if it goes lower, it's harder to distinguish for the random forest classifier. And you can see that for most scenarios except where there's one or two d2s that are in there, the accuracy actually goes down in distinguishing DNS and data traffic. And the second solution is to use our peer based check rules approach to basically hide the destination information. Again, here, you can also see for the peer based ones, it goes always a little bit down. And the last solution oh, wait. And but then with the peer based approach, then length becomes important again. So you actually want to use this blockwise approach that I talked earlier. But you can see there, there's also a little bit of importance here in the end, which is basically the padding we did to the feature vector. And for that, we actually recommend to use the padding option from the cacheable OSCORE draft, also by Christian and Marco, to basically also equalize the length of the last block because the last block sometimes even give can give this information away. And you can just pad the lengths of the last block to the lengths of all of the of your blocks that you had before. And the last solution we propose oh, now it doesn't work anymore. Okay. Is to use Onion OSCORERE with randomized IDs. As you can you can see here, here the CoAP message ID and the CoAP token are actually what is telling. And in the next plot, the feature importance has changed. So now it's just a code and the addresses, but the overall accuracy decreased anyways. And the only thing that is still a little bit telling is the OSCORERE partial IV. So it's also basically a sequence number that is growing. So there is still a need to hide that somehow. And from that, we basically drew our final conclusion and protocol recommendations. First of all, alight as much headers as possible, for example, our peer based rules approach, then randomize and encrypt the headers that you cannot delight, so either with onion CoAP or the encrypted PIV when you're using OSCORE, and use blockwise transfer to equalize the lengths instead of EDNS(0) padding and the core padding option to equalize the lengths of the last block. So my question originally sadly, I wasn't aware that there's already a working group plus call for the guide DNS guidance draft, but my question originally was, should we draft a recommendation document or maybe contribute to your document? And if you have any other questions, please ask them. If you want to read our paper, there's a preprint. There will also be a publication in the IEEE Explorer. It's not out yet, so don't be confused that the DOI doesn't lead anywhere yet. And if you want tolook at our results and our data, you can do that on Zenodo. Yeah. Thank you.

[00:58:28] **Christian Amsüss**: Thank you. Christian Amsüss, which of those things that you're presenting as parts that can be go into the evaluation do you think are realistic for someone who would be the audience of of Jim's document to implement? Because I guess that, like, on your OSCORERE is some way from deployment. Yeah. I don't know how realistic it is for a device implementer to set things up around shake, but I guess implementing DoC would be easier for them. So it's like, which are the parts that you think make sense and how much impact does like, what's what's the the kind of the best improvements in terms of privacy that you can get for those?

[00:59:09] **Martin Lenders**: I guess if you are already having DoC or decide to deploy DoC, I guess, with equalizing the block length using Blockwise transfer is already something that you you can do. Everything else, of course, first needs to get deployed. Thank you.

[00:59:32] **Jim Mosley**: Martin, thank you. I mean, the obvious thing sorry, Jim Mosley. The the the obvious thing is that we take DNS overcope, go up, and put that within the draft we've got as as one of the ways that the DNS traffic can be encrypted between device and resolver. So we should definitely talk about that. I don't know what level of detail we should go into, but we obviously don't have

[00:59:58] **Daniel Rice**: time to discuss this.

[01:00:00] **Martin Lenders**: Do a follow-up document. Keep keep

[01:00:02] **Jim Mosley**: collaborating on that. So thank you very much.

[01:00:04] **Martin Lenders**: Yep. Oh, by the way, another thing, of course, you can do is the randomization of the transaction IDs is also something that is already mentioned in your draft, so that you can also do, of course. Any other questions?

[01:00:24] **Hannes Tschofenig Tschofenig**: Hi. This is Hannes Tschofenig. I had a student working on it was in a different area, IPsec with IPDFS. Some of you may know that work. I'm trying to find out what type of traffic is sent encrypted in a t IPsec IPsec tunnel. And the conclusion from that work was that batting up the the packets to a unique or unified lens actually didn't help. So that was a little bit of bummer. Mhmm. Would have been so nice because it would have been a first easy entry point. But the machine learning machine learning techniques find this out pretty quickly from the from the

[01:01:08] **Martin Lenders**: pacing of the packets. Mean, that is also somewhat that's why I didn't mention it as a leak because we didn't find it that that significant to of a leak that the packets are of different length. And so equalizing the lengths only brought the accuracy down a little bit, but putting that on top of the other recommendations also helps still.

[01:01:32] **Hannes Tschofenig Tschofenig**: Well but that's what Christian was referring to. Like, what's the what's the practical thing you can do and, like, something that using sort of obviously, there are fancy technologies that exist that you could do use. But, unfortunately, they come all with sort of challenges. Right? So my my conclusion was from the IPsec experiment was there isn't something that is easily that can easily be done if you care about those type of privacy challenges. On the other hand, most people don't care about these privacy challenges to begin with. So that's then that's a just sort of, like, the positive note on that. Mhmm. But but I wouldn't I wouldn't lead people in the wrong way to believe that, oh, if you look lose block block by transfer, it will actually get you much.

[01:02:31] **Martin Lenders**: Any edit? Anything else? Okay. And thank you.

[01:02:38] **Alexeyey Melnikov**: Right. So I think the short term plan is you will collaborate with Jim and add some section about DNS of a CoAP. And we'll see how it looks.

[01:02:48] **Martin Lenders**: I was planning to read the draft until Thursday anyways again, so I can comment on the working group last call. Yep.

[01:02:54] **Alexeyey Melnikov**: Yep. K. Thank you. That's Is it my turn now? Yeah. I and Michael is not going to be here, so I think so yes. Oh, okay. You have Let me just one sec.

[01:03:26] **Henk Birkholz**: I did. Take away the clicker. Oh, you want? Oh, you want?

[01:03:36] **Daniel Rice**: I'm gonna use the clicker just in case.

[01:03:38] **Henk Birkholz**: Okay. Yeah. It's it's it's right here in the case of emergency. Yeah.

[01:03:44] **Alexeyey Melnikov**: This one? Yep.

[01:03:47] **Daniel Rice**: Yeah.

[01:03:47] **Alexeyey Melnikov**: Okay. And one second. Okay. Try it.

[01:03:54] **Daniel Rice**: Okay. Thank you. Good morning, everyone. So today, I'm going to be giving a short update on privacy preference declarations for home networks. So you'll notice that this work is now split across three coordinated Internet drafts. And I also mentioned this earlier, but I have a working reference implementation behind this. So this has been fully implemented, feature complete. Seek me out afterwards, and we'll show a little demonstration with a Smart Bulb and a router. So I want to use this update to explain where the drafts are now, what the implementation tells us, and where I most need discussion and participation. This is not meant to be a full walkthrough of every detail. The aim really is just to give enough structure that people can see what the work is, what's changed, and then where review would be most helpful. And I'm gonna stay at a fairly high level here and leave room for some follow-up afterward. So the core problem really is that household privacy control is very fragmented. So today, privacy choices, they're mostly expressed service by service, device by device, very different language, very different control surfaces. In practice, households mostly encounter, sort of vendor authored privacy terms, vendor specific controls. They have no common way for the most part, except with some web technologies, to present their own privacy preferences, to devices, and associated services. So this creates an information asymmetry for households, and it also pushes vendors towards one off control services. So I I want to emphasize it's not just a semantics problem. It's also a control problem. Each household can usually only choose among the options that a vendor actually decided to expose. If they didn't expose them, then it's not an option apart from maybe don't use the service or don't use the device, which is unfortunate. If a household wants something, specific, well, again, it has to use what knobs the vendor decides to expose if any. So the goal really is to create a participant facing way for a household policy to be expressed once and then received in a common form. So this is useful not only for households, in fact, but also for manufacturers and operators who would otherwise need many separate privacy specific interfaces. So the project really is trying to reduce friction on both sides, more meaningful expression for the household, and then a more predictable integration point for the participants who are receiving the policy. So since earlier versions of the draft set has been split more cleanly, we've got the architecture draft, which now focuses on roles, trust, life cycle. The protocol draft now carries the participant facing operations and messages. The taxonomy draft defines the shared semantic floor that makes comparison pop possible across different vocabularies. Privacy policies vary very much in terms of their overall vocabulary, so this is quite important. But it's it's quite different from the remainder of the work. The protocol draft is really the main structural addition because too much participant facing behavior was previously implied rather than sort of explicitly specified. So the current posted revisions are architecture v 10, protocol v three, and then taxonomy v five. That separation also makes the work hopefully a bit easier for folks to review because criticism can land on the right layer instead of getting mixed together. If something is wrong with trust boundary, that belongs in architecture. If a message or object is wrong, that belongs in protocol. If the comparison semantics are wrong, that belongs in taxonomy. This has hopefully made the work a bit more coherent and should also make it easier for others to engage without having to reopen the entire design all at once. Right. So at a high level, what happens is that the participant discovers candidate endpoints, selects one, establishes trust separately, retrieves an effective policy, acknowledges that exact policy instance, and then renews or reassociates over time. So the important thing there is that the participant is not just receiving a vague policy advertisement. It receives one concrete effective policy instance, and then the acknowledgment ties back to that exact instance. The boundary matters a lot here. The participant facing contract actually ends at the, service endpoint. Discovery gives only candidates, and endpoint trust is a separate step. I wanted that separation to stay explicit rather than being hidden inside the protocol. The acknowledgment is a protected receipt for one policy instance. It is not a general compliance claim, and the baseline is intentionally a privacy signaling and record keeping mechanism, not an enforcement architecture. The reason for this is practical in nature. I don't want the first interoperable baseline to depend on one control MUDel or one router behavior or one assumption about how devices should be blocked or constrained at runtime. So this keeps the first versions of this narrow enough to be useful without forcing early assumptions about control behavior. I do think future work may add stronger control responses or even policy carried enforcement instructions, but I don't want the basic architecture to depend on that from the start. This keeps the barriers to adoption for folks like IoT device vendors lower and avoids turning the work into a security enforcement mechanism when the central problem here is really about privacy preference signaling. So the taxonomy matters a lot here because declarations and household policy need a basis for matching even when vendors are describing the same kind of data flow but in different local terms. So different vendors can use different words for the same thing. They can also use the same word in meaningfully different ways. So the MUDel here needs to tolerate that variability, including cases where local terminology is broad or intentionally ambiguous. Anyone who's read a privacy policy in their life will note this, without giving up the ability to compare against a household policy. So what this means is that the MUDel allows for, richer local vocabulary, but comparison relevant terms have to reduce to a shared core. So in this example, two vendors are using different local labels for what is effectively the same kind of declaration and then both reduced to the same core terms. So once that reduction is available, the household policy can then compare once against the shared core instead of interpreting each vendor vocabulary separately. And this matters also across different households, but even more obviously across different vendor ecosystems inside one home. One might think, for an example, you know, Google versus Amazon just as one instance. Right? So the household should not have to mentally normalize each vendor policy in the home. The vendor should not have to guess every household's vocabulary either. So the taxonomy is there to make that normalization stable and computable while still re leaving room for richer local expression above the shared core. So behind the drafts, as I mentioned, there's already a working reference implementation. Again, I'm not going to try in the short time that we have allotted here, to show the live walkthrough, but the implementation is definitely far enough along to exercise the end to end MUDel. So what I've got is a concrete implementation approach for participant integrations and for a household side infrastructure that would potentially run on, say, a router, a a MUDem. It already covers the main end to end flows, including the exact policy retrieval and acknowledgment, renewal, reassociation, also conflict signaling. So if the household defines a policy that says a and the vendor defines actually, sorry, the the other way around. If the household defines not a and then the vendor defines a, well, then obviously there's a conflict, but richer conflicts are also possible to to signal here. So even though I'm calling this a demo, the important point is that this is not just sort of a a set of mock screens that I've got to show. It's a real implementation path, a real test bed for the the design choices that are inherent in the drafts running on real IoT devices. So if this is relevant to your work, I'd love it if you could please find me after the session during a break. I'd love to walk it through live. And if anyone is interested in source code access, the public facing repositories are absolutely planned, but they're not in place yet. And so the current access needs to go through CableLabs, GitLab, and that process. So just bear with me before we get this in a more public facing area. So right. So this is one way to realize the MUDel that I mentioned in practice. So on the policy signaling side, the participant interacts with household endpoint on an open WRT router, and it's backed by a separate household policy authority. Again, it runs on the same router, but it is a separate process. And that's distinct from the participant's ordinary application interaction with a connected service. The top row that you see here is policy signaling. The lower row is ordinary service behavior. So I wanted to kind of contrast those. Keeping those distinct is very important to the design of these this protocol. I do not want PPD to be mistaken for the device's whole service protocol. It's an additional privacy specific interaction, and it sits alongside normal service behavior. So what the implementation really is demonstrating is association with an exact policy receipt. You've got a policy change and then a reassociation as a result. Runtime conflict handling is a separate signal rather than part of the baseline contract. And this also gives us a concrete way to test whether the architecture boundary is clean enough for realistic deployments instead of only looking plausible on paper. Right. And then I'm I'm gonna leave some time, you know, for questions or potentially for folks to get my contact information or, again, you can always meet me in the hallway. But what I really need most now is not just protocol or critique in the narrow sense, but I'd really like to have a discussion on architectural scope, trust assumptions, potentially taxonomy extensions, semantic boundaries, and on deployment requirements, especially at scale or even potentially outside of the household setting. I'm sure that this has, ramifications, potentially for commercial deployments. I also would love to have some feedback on where the current baseline is currently bounded and where companion work may need to add behavior. And the most useful participants here, I think, are probably not only protocol people, but even device vendors, gateway platforms, operators, service providers, people who think about privacy semantics or deployment reality really all have something important to add here. So if you care about the terminology of privacy, the deployment reality, the trust boundaries, ways to make this scale more, or even whether this belongs in this venue, that's all very useful input. The design direction, taxonomy proposals, and deployment requirements are also valuable here as protocol critique. And if the live implementation would help make the discussion here more concrete, as I said, please grab me afterwards, and I'd love to walk through it in some more detail. And that's that. Thank you. So any questions, discussion? If not, thank you very much. Ah, okay.

[01:15:29] **Jim Mosley**: Yes. Dennis, thank you. It's fascinating. This obviously covers a a a big area. Yes. The impact is potentially more huge. I wondered oh, sorry. Jim was listening, actually. I wondered how this works with regulatory frameworks. There's there's a big intersection between regulatory frameworks and policy Yes. And this, I guess, just I I know that's really high level way above the protocol.

[01:15:54] **Daniel Rice**: Not at all, actually.

[01:15:55] **Jim Mosley**: Would either give impetus to this being implemented Yes. Or potentially barriers or possibly both. So Yeah. If you got a comment on that.

[01:16:05] **Daniel Rice**: So how shall I put this? So it it's it's nice that we're here in Europe to discuss this because coming from The United States, that policy angle is significantly different. Here, there are regulatory norms which one might encode in all household policies in order to cover, you know, the basic compliance requirements, that the law affords. But, again, the actual, you know, Internet drafts are sort of agnostic to this fact. But I think you've picked up on a very important aspect to this, which is that, yes, absolutely, you could encode all of these regulatory norms in any protocol. The vendors, you know, where the when they write their devices, you know, declarations may also do the same, in order to, you know, impart upon the user, automatically without them having to read a 90 plus page policy, what those norms are as well. And then being able to automatically deconflict this, you know, such as in the case where conflicts do exist may also be a very useful mechanism. And then on top of this, as I've mentioned, you know, enforcement is not baked into this because I don't want that to be sort of part of the initial architecture, but it it certainly could be. Right now, that signaling mechanism certainly allows you to get that information across the wire, but there's there's more that could happen as well too. So, yes, there's definitely a lot of implications for potential regulators that might look into this, but I've I've I've very deliberately been sort of coy about that in in the drafts. And I'll leave that as an exercise to the reader to some extent.

[01:17:40] **Jim Mosley**: Alright. Thank you.

[01:17:41] **Daniel Rice**: Thank

[01:17:41] **Hannes Tschofenig Tschofenig**: you. Hi, For if I'm a IoT device manufacturer, what would I need to do to make it my product work with this framework?

[01:17:54] **Daniel Rice**: Yes. At the moment, the baseline is absolutely nothing. So if you want your device to simply operate the way that it's always worked, you don't have to do anything. If you want it to be open to receiving the policy from the household, then there is, as I said, the reference implementation, which can be adopted, adopting that protocol. Essentially, you know, at a very high level, what this involves is, registering with an endpoint that exists on that on the household network, and declaring that you are a device that is compliant with the protocol, receiving the household policy, and then optionally responding with your own policy, and then there's deconfliction actions that can happen after the fact.

[01:18:37] **Hannes Tschofenig Tschofenig**: But if I if I don't do anything, the household would have to be configured to fetch my my privacy policy from my from a from the product presumably somewhere?

[01:18:50] **Daniel Rice**: No. No. So if if you choose to be a vendor which does not implement the protocol at all, the idea here is that we don't want to, in any way, come in the way of you operating on the network. However, the household could conceivably, you know, implement a policy which says, well, you know, devices that don't implement this this this protocol aren't allowed on the network or get segmented off to a separate IoT specific network or even a set special DMZ or what whatever the case may be. Again, that's that's an implementation detail as opposed to something which is actually enshrined in the protocol itself.

[01:19:24] **Hannes Tschofenig Tschofenig**: Okay. Thank you. Yep.

[01:19:31] **Daniel Rice**: Okay. Well, if if there are no other questions, thank you very much.

[01:19:36] **Alexeyey Melnikov**: Alright. Thank you. Within minutes, Kelly. Well, I mean would be the Yeah. Well, there is no presentation. Okay.

[01:19:51] **Daniel Rice**: So

[01:19:54] **Alexeyey Melnikov**: we are into slot. We actually only ask for hour and a half. So I was like, yeah. Like, I was panicking. Like, why is, like, forty minutes remaining? So and we're basically ten minutes early because Michael is unwell. So with that, any other business? Anything people want to bring up? If not, you can have an extra ten minutes back.

[01:20:22] **Hannes Tschofenig Tschofenig**: Or forty.

[01:20:23] **Alexeyey Melnikov**: Well yes.

[01:20:26] **Daniel Rice**: Should I go get my demo hardware? Yeah. Yeah. I can go get it. Okay.

[01:20:30] **Henk Birkholz**: We have the we the time. So sorry. If the if the room is interested, of course. But I think we have ten minutes left, and that is maybe I've been out of time.

[01:20:42] **Alexeyey Melnikov**: Oh. That's okay.

[01:20:44] **Hannes Tschofenig Tschofenig**: Wait. Nobody's doing anything. Yep.

[01:20:47] **Alexeyey Melnikov**: I I mean, there doesn't have to be.

[01:20:49] **Elliot Lear**: If not Okay. I can do

[01:20:50] **Daniel Rice**: it later. So

[01:20:50] **Henk Birkholz**: I'm time boxed. I might be the time boxed chair, but but Alexey is capable of doing everything.

[01:20:57] **Hannes Tschofenig Tschofenig**: I'll be right back. Oh,

[01:21:01] **Henk Birkholz**: this is we plan to do that. No. This is this is a add on to the session. Our session ends in ten minutes.

[01:21:07] **Elliot Lear**: So I think the room

[01:21:08] **Hannes Tschofenig Tschofenig**: is empty. Yes.

[01:21:09] **Henk Birkholz**: Yeah. Exactly.

[01:21:11] **Alexeyey Melnikov**: Let's end the session, but people have can use their own. I think that's so

[01:21:19] **Martin Lenders**: alright. Thank you all.

[01:21:23] **Alexeyey Melnikov**: So with licensing, I'm actually I'm thinking to change my mind and start it now. That's cool. Because people can do reviews this week. If I do it the meeting, you sure? Look. If we get no comments,

[01:21:40] **Elliot Lear**: we'll have to redo it on Sunday.

[01:21:42] **Henk Birkholz**: Okay. Yeah.

[01:21:43] **Alexeyey Melnikov**: What do you think? I can do three weeks now, and then we'll see what if people manage to get reviews this week.

[01:21:50] **Henk Birkholz**: Yeah. Exactly. If you do three weeks starting this week, they can go get can can catch Elliot on the in the hallway, ask questions. Okay. That's

[01:21:58] **Jim Mosley**: fine. Okay.

[01:21:59] **Henk Birkholz**: That's fine. But yeah. Okay. I'll just do this. So in site meeting organizations sorry. I've I've organized the site meeting that is not. Okay. And it's just shared with media. What's the topic? Observe.