Internet Engineering Task Force Interim Meetings, 21 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CORE WG Interim Meeting, 2021-01-21

Description

CORE WG Interim Meeting, 2021-01-21

A

Important thing this is an official uh itf meeting first quarter meeting for this series. We are going to have three interims uh until atf 110, then the note 12 applies. Please, please get familiar with that, if you're not already and before, switching to the main item on the agenda today, which is the cachable oscar document, uh I just wanted to check quick with kirsten about the status of the core conf documents.

B

Yeah I'd like to know that too, um so I sent some some nits to the the authors that I found in my shepherd review and we got uh new versions of the documents I haven't got around to actually checking them, but I assume they are addressing the needs, except for one, uh which is that the media type registration text in yang zebo is still isn't ready for for putting the question in the media types registry email list, and that means that we can't really fill in that part of the shepherd report and I'd really like to have that that duck in a row before submitting the shepherd report.

B

So that's where we are at the moment.

A

So that's young c bar and yeah. I also just seen your mail. uh I think your library is probably just fine, because I also saw your exchanges with if I give about that too yeah, uh but I saw recently all the four documents resubmitted. So I suppose that seed and comey, though, uh are still requiring some some work to do on the needs.

B

Well, sid should be done again. I have to check that uh comai is, is a little bit longer so um yeah, let's see where we are with that. So maybe we will need new versions of of uh these two documents. Komai and yang ziba are certainly young zebra, but maybe coma as well.

A

Okay, so please double check about seed, also, if that's actually the intended final version, I know michael, is especially eager about that document. Moving forward, hi michael.

B

Yeah right, so the the problem really is that that if you have an ongoing communication between two people who are really slow in replying to the email that that's uh not the recipe for things going very well. So that's where you are at the moment.

A

Actually, thanks for taking care of the needs and yeah when you say so, we can really finalize this, but.

B

I really want to get this done this month.

A

Same here, okay, thank you kirsten.

A

That said, we can switch to the main topic for today uh casual score, and I guess you will see my screen, but christian will present actually.

C

Yes, so um what I'd like to do today is to give you an update of what we've been doing with cashable oscore um and try to get this into a direction where we could make possibly gorgeous working groups interest in it and where we should develop this further.

C

This has been in parts driven by research. I've been doing with harvey hamburg on evaluating this. So as a result, um there is there are no implementations, but let's get started from the beginning and next slide please. So um the the the kind of big picture is uh in general. We can't um do caching of oscar requests and as a mitigation, the proposal is to allow clients to opt in to a mode of oscore where they produce um requests in a deterministic fashion and can then all arrive at the at the same request.

C

This consensus request that can even be cached by proxies that are not part of the group and still deal out responses to the group members um in the version that we would like to publish as a dasher one um in the next probably a few days. um We've all we've processed the input from the last meeting. um We are now building requests in pure in something more like pairwise mode and much of the distracting content about what other forms of consensus requests.

C

Could there or can can there be, um is being removed because that's just more of a historic um overview on how to get there and not and just distracting from from the from the actual topic next slide. Please.

D

Oh uh christian yeah, while I remember, uh could you please please go back to the previous slide, so this is a group ghost oscar consensus request? Yes, yes, you see, I actually managed to read something before this meeting, which I'm I'm extremely proud of. So I'd like to take the opportunity to to ask questions so the consensus request. You have two different types of consensus requests. One is the deterministic uh request and that is a pairwise request.

D

Yes, uh so when you say group or score, you mean not a group mode request here.

C

Yes, the the request is actually not in group mode, but it's using group of concepts responses in group mode. So it's it's building on groupos core of the request. Right is not a group, a group mode request, yeah.

D

That was a confusion I had when I read the first time I thought consensus request was a group request and then it turned out to be pairwise. Okay, yeah! Yes, that's the clarification. Thank you.

C

um So the the all those requests are sent from so while these requests are sent from any client in in terms of uh key material and identifiers, um there is one um particular group member that is decided by the group manager and the whole the kind of the whole key distribution protocol that is used for this purpose, and this member has no public private key pair.

C

um But hazard has an id like all the others and everyone who wants to interact with that peer will notice that either it is a deterministic peer or it has some data in the key material that the participant doesn't recognize. So it can't kind of try communicating regularly with it, um along with the key id there's, also a hash. Also, there are other rules about the hash algorithm transported.

C

We have not kind of um hammered that out to the details of how the kdc do would do that, but which hash algorithm to choose and the length of that hash is inherently something a property of of that map of that deterministic client group member um next slide, please.

C

So what what a client does is it um it's, for it decides for a request that it wants to send it in in deterministic mode, which means that it sacrifices a few of the properties that oscore gives it in order to get that get this cash ability, and then it starts building the request like it were, as if it were sending a pairwise request, but before it gets to the encryption part, it hashes everything that will um affect the encryption, so it hashes the the plain text and attaches the aed and the sender key and then uses that instead of the shared secret which it could not derive because it doesn't have a private public key material in the derivation process other than that it pretty much works like a like a pairwise request.

C

E

C

That just a brief moment, this ensures that the key that we are using here is only ever used for this very um cryptographic operation and only with those very parameters and never with anything else that could later uh contribute to month's reviews. Go on.

D

Yes, this construction here in three, um so what you typically would have in in the hkdf, you would have some salt and some shared secret and info and l, yeah or something yeah, and in this case h is not a secret right. H is not.

C

A secret no, but the center key of c of c star is the secret is secret.

D

Yes, but you're actually sending h in plain text. Yes, so I wonder if we want to change that somehow, so we have.

E

D

H in plain text, because that is what the server is using to get to the same key again, that's fine, but we may want to have a secret which we put into, which depends on h, which we put as a second uh parameter in. In I mean.

C

We we are doing an hkdf to derive a secret from that publicly known from from from some secret information to, and some publicly used um publicly. Isn't that right. What it's of what the hkdf.

D

Is for um that's right so that it might be sufficient. But I'm just noting that this is deviating from the from the pattern that we are using.

C

Yes, so in in the pairwise mode here in the place of age, there would be the shared secret.

D

C

um While the rest of this is the same, um my understanding of hkdf is that as long as either the salt or the secret is kind of you get the better of either. But if that is not the case, we might need some switching around here. Yeah.

D

I I don't think it's I mean making this secret is not a problem, because you share a secret among uh among uh participants in the group, I'm just noting that this is a deviation, so we might want to consider what that what implication that has.

A

uh Just the comment: if you switch them, you deviate as well, because normally you have a sender key there. Yeah.

D

No, it's not a matter of switching replacing h with something secret which has h as an input.

F

D

C

um I I think this would be just another round of hashing, but um we can. We can definitely go through that in more detail, yep um to show kind of basically look up the properties that hkdf has or needs to have uh to ensure that it's good to use this with uh with a public input at one of those places.

C

B

So I I have a pretty dumb question. um The whole thing is about deterministic requests right. Yes, so I cannot use this for sensor data because sensor data change, so the same request gives me a different response over time.

C

So you cannot use this to transmit sensor data by kind of put making a deterministic, post or deterministic put, but you can phrase the request in a deterministic fashion. If it's a if it's a get and then the response will be depending on the on the state of the resource.

B

Yeah, but that means that there are different signed responses floating around. Yes,.

C

There are different signed responses floating around, and this is not about having the same signed response all the time, um I'll come late. um So the what probably matters here is that the response is not sent with the same key, but this response is sent in group mode using a sequence using a proper sequence number and um and a signature, and not with that key. That can only be used for this. One request.

B

Okay, so we we, we have some measure of freshness in there we have yeah I'll come back to the to the.

C

Size, I'm just.

B

Trying to understand how this gets by without the freshness here and and yeah, okay, yeah.

D

um So yeah, okay, no, no! No! No! No! Okay! So just to I don't know if it helps in any way, but in grupo score we define the mode where you you send in group mode and you get the response in pairwise mode. So it's basically you send a multicast and you get back uh a unicast, and this is this is apparently the reverse. Then you send them pairwise and get back. You send them pairwise and get back something.

C

That could even be multicast out if there are, if there are many clients listening to that and in in not not with physical multicast, but with uh proxy responses, which kind of do a similar fan out. We have just that the response gets sent to everyone at least everyone, whoever requested it.

D

Okay, please go ahead. Thank you.

C

um I just see a question on on on jabra over there.

C

C

Gonna yeah, I think that's something to address at the discussion at the end next slide, please um so, as we already had it, uh the the request request hash gets put into the request in in an unprotected uh in in plain text.

C

um Then there's a bit of a quirks that we will have to do that is in group, boss code. We have this request key id and in order to get proper request response binding, um we use the request, hash or possibly something derived from it. Currently, it says request hash um as the request kid, because that's um that's what ensures that the responses will will match here and then the um request is encrypted. um It gets put into a fetch request.

C

Not a post request like an observer request would be in order to ensure that the cache is on standards cachable and off. We go um the server next slide. Please um that receives it um can take the can.

C

Take the public cache do the same key derivation um and decrypt it now, um given that it just derived this security context, it doesn't have a replay window to check against and the basic or it has a fresh replay window and the replay check will always pass, um but it's in this kind of cases where it can't be quite sure whether this is not possibly a replay in some sense, so it will have, will always have to send a known sequence number in order not to accidentally commit non-reuse.

C

um There's two more checks that the server has to do. One is that it checks whether the hash is actually matching the plaintext, which it of course, can only do after unprotection.

C

Basically, if that check fails, the client has already messed up terribly and reused. The non-scroll uh reuse, the keynotes pair for something, but it's still good. If the server can can kind of raise the flag here and the other check it has to do. Is this whole game only ever works for safe request?

C

You could probably extend it for an important request, but I don't think there's too much value in it and if it's not, if, if that's not okay or if there are any other permission, issues like um the deterministic client is not even allowed to access that resource. That gives you a 401 protected response next slide. Please.

C

Then other than in in kind of regular oscore messages, the server can actually set a meaningful outer maximum age which allows the cache to make an informed decision of about how long to keep it and sends it back. And here we have that part in group mode. So it does a signa it signs. It protects the message with its own group: sander key.

C

It uses an own partial, uh unknown sequence, number that it attached to it and it performs a signature operation which gives us source authentication for the response, and then it goes out in a 205 response.

C

Next slide, please so that was the the mechanics of it um as kind of things that we explore on the document as well, but are probably not crucial to the whole operation, is that um you can send those requests to a group as well. So you can have this many to many uh group situation, although bit care must be taken to send the responding server's key id then, and if, given that this, this whole setup allows an adversary to see that different requests are all hitting the same resource.

C

It might be a good idea here to introduce padding in the responses if the responses are not constant length. So we um add, we introduce this padding option as something that you might use um in this context. Kind of in regular oscore, the the attacker can't know which resource is being requested.

C

Now, I still can't know the very resource, but it can at least observe that all those requests are going for the same resource and the responses that come back, I'm obviously different in some way, so there's something going on and that's a way of how to how to hide that next slide. Please- and this is one I'm I I want- we probably should spend a bit of time on um comparing the security properties to what we usually have in our score, so usually in aust core. We have a strong threshold statement that says the response.

C

um The server of this response was created after the client created the request. Now this property is lost, because if we did not uh make this property lost, then an older, an older cash response could never be used, so this is crucial for um for caching, what we still do get is relative freshness, in the sense that we can do something like.

C

If we do an observation using this, we can still order the responses and we get something um and we get something like um kind of some kind of trust on first use freshness in the sense that if we ever receive a response with that particular sequence number, we can apply the same processes with observation and reject any later response, with a lower sequence number on the for, for that particular request.

C

If we want to compare them, then request confidentiality that is um is reduced by a tiny bit, which is just enough to ensure that the cache can pick the right response to serve. It might be worth pointing out here that, of course, if the clients um do have some variation in how they form the request say, one sends an accept header and the other. Doesn't um those requests still do not look the same and don't paint the same cache key but kind of it's a start and any application that uses.

C

This probably has rules for for doing normalization on the request, at least at a best effort base and the kind of hardest property is that we lose source authentication for clients, because we want. We want a response to be usable for every client that might request it, even if it doesn't go through the server.

C

So if we, even even if we, if we kind of manage through through other means to preserve client source authentication for clients by say putting a signature somewhere in a in a non-cache key option in practice, that would still mean that the responses that are out there might not reach that very client, but a different one. So this is kind of by design that this is lost.

C

Source authentication for the server is an important property that is obtained that is preserved, so no still. No so still, no member of the group can impersonate the server.

C

Questions here.

B

So is there any way to put back in request confidentiality and at least uh against outsiders, um the.

C

Thing is we want requests to be aggregated by an a proxy that is an outsider yeah, so the the the information that the outsider has that an outsider has to be able to obtain is that two requests are for the same resource right if you can't obtain- and that is the only information that we leak compared to regular score.

B

B

Maybe it's worth thinking about a situation where the proxy is an outsider to the group, but still is something that that is more trusted than a random attacker.

B

I'm just thinking whether there's anything that can be done there so.

C

The a comparable setup that I know that can do such things is: tahoe loves the the least authority file system um where they differentiate between can verify the response, but cannot read it or can can read, can can interpret the the path but cannot do much more.

C

I assume that something like this could be set up, but it would be a lot more complex because it needs different levels of keys and different levels of group membership.

B

Yeah, of course, you can always run dtls to your proxy, yes or unless that asks.

C

It's probably worth exploring, um but I would um my expectation on that explore so uh on.

C

Whoever is taking notes, please um kind of put an exclamation mark with my name there, um so that I add this to my to my points there, um but my expectation on the result is that it would be a lot more complex and it's probably out of scope for an initial version here and kind of whoever has a use case, for it could could look into it more deeply, but I'll take at least a few first steps and and see where how far one can get here. Thank you easily.

E

Christian, yes, so are you finished? Are you at the end of your slides or.

C

um There is yeah, there's there's one more point, that's an open question and then I'm going to next steps and general discussion.

C

So if you have the question that you mentioned on irc, I think we should that should go after and if no one else has questions about this very slide, I would briefly go through the rest of them.

D

Yeah, um I don't have much to comment here. I think that's. I just wanted to say that some of the properties that you want is sort of reducing security compared to oscor, but that might be okay in this situation and it's, I think the emphasis here is on the limited and on the simple setup that you have uh and that I think that's fair. So I don't have any objections to the setting. Although I haven't actually the details needs to be covered.

D

um I mentioned one of these aspects on the key derivation and I think there are the details that we need to look at. Yes, how to derive the keys and there is for yeah, but we can go. These are details we don't need to discuss here.

B

D

For example, the request key id is now the hash and so on. It's it's it's nice, because it's taking an ex an existing concept, and it's using that, but pairwise keys is no not pairwise anymore. So yes, it's it's! It's using.

C

The mechanics- it's not hoping to get its very properties.

D

Right so and that we need to check yeah, but it looks good otherwise, I think so next slide.

C

Please kind of one one point that we know that is um that that might raise questions is that we have now two ways that the server can say this. This request is bogus and they don't come from. They don't all come from through the path that the crypto primitives usually guarantee uh constant time for so, if the, if the hash on the, if the hash, if the hashtag fails the client uh an attacker, might get information about whether it gets the the a aeid tag right now.

C

I think this is okay, because the basic basically in a regular case- that's that's already a client's fault and in any other case um the attacker will have a much harder time guessing guessing uh guessing a good, aeid plus hash pair anyway than with regular aead, but still it's kind of one of the things that we will need to go through while going through all the other documentation of. Why is this? Actually all? Okay next slide, please.

C

So currently there are a lot of pending changes in the editors copy. um My plan is to up to submit a one in kind of the next days two week or so.

C

um That includes all those changes, especially those that came from actually implementing it. So eio co-op now implements what is what it says in the editors copy.

C

We've been running um much of this in the in the experiments um for for further comparison of co-op and uh and icn setups and um marco has already announced that he would like to do something on californium.

C

So that's it from my side.

D

Next slide, please just curious on this. What's one reason why you made this is because of there was some bad performance comparison in the previous setup. uh Is this: how is it now? What does it look like? Do you have any performance measurements.

C

Yes, uh so the the measurements, so I mean, of course, this is all for for setups that are tailored towards showing that this aggregation can can or cannot work, um but in the um in the setup that in the setup that we did on the iot lab, the preliminary results indicate that we, basically we get all those nice properties of that, otherwise that you otherwise find in information-centric networks where the caches can, where the data can really be distributed throughout the network um without hitting the server too much.

C

um The the overall energy consumption should not be impacted too much, even by the even by the asymmetric operations that we suddenly start to introduce because they, at least if proper hardware is used. The the energy consumption of the signature operation is in the order of magnitude, of a request of a radio transmission and sending send sending kind of sending the same package to everyone instead of sending it to the next top or the next two hubs once and then letting them distribute the information um pretty much makes up for that.

C

So the general results are good. um That, of course, are only from kind of yeah sure.

D

I understand another question: was this the use case where you announced uh potentially distribution of firmware updates? What that.

C

Was this yes, so this is. This is definitely something that can be that can be used with firmware updates, because if a client, if, if clients, if, if um clients, use a pull model for firmware, where they've obtained a manifest and then basically get the resource, get the firmware from the from a large central server, um then they send their block-wise requests to the server and as they know, that kind of they're already giving away that they are fetching firmware because they are obtaining a megabyte of data. And what else could it be?

C

They can opt into this blockwise uh helped into the terministic score, send their send the requests and many other nodes on the network will already have fetched that firmware and they can use their the responses they got.

C

Send them to the club, send them to the requester, and then the requester can get uh get a representation of the firmware without ever had ever hitting the server while preserving.

E

So that's really a killer use case. I think um as I uh there so. I think that you're telling me, though, that it's not just a proxy that can or cash that can respond, but that any member of the group.

G

um Not even any member of the group, any node I mean um so this this all right.

E

That's right, it doesn't even have to be member of the group any any node that heard the request could respond if they had it.

C

E

C

um Maybe let me let me briefly kind of explain a bit of what we've been doing in the ndn comparison, because this is motivating a lot of this. um The way we often think of of um co-op is to use it end-to-end from ip to ip address, but we have all those facilities for processing between.

C

So um no matter where we sprinkle in a proxy, it can be useful and in the um the the easiest place to put a proxy would be in the um in the border, router of a between six lowpan network and the rest of the internet, and then that border router could have a cache of that firmware and that already kind of really takes a bit of stress off the of the uplink.

C

But really I mean compare a dsl line with uh with a 6lowpan network and um the 6lowpan network won't take won't take down the the big server.

E

Actually, it's it's in a number of cases, it's it's uh for firmware update. It's actually rather um important that observers on the uplink or on the server can't tell which nodes have upgraded at what point.

C

um Good point didn't think of it like that, but that's a bonus.

E

um But aside from the stampeding heard of elephant's problem, okay, um the privacy issue is, is: is there um and then the other question is um you know, does this extend and I don't think it does, does this extend to the point where uh a node never needs to communicate with uh the source of the firmware?

E

C

To uh so so, the the one thing is: if you never communicate with the source of the firmware, you never get a freshness statement, of course, okay. So unless you have some synchronization in place, be it because you have a gps time beat for some other reason.

C

That would give you anything that you can put the results in relation to then you could always be a year behind and watching watching recorded television um as soon as you have something to hold on, um you can pro. So if you don't have anything to hold on, I would be careful to use this for firmware updates, because then you could be kind of someone could be slowly skewing your time to the 80s um there's a movie for that, um but other than that. Yes,.

E

So please put that into the the use case uh uh uh uh area. um uh I I'm sorry, I guess we're getting into that conversation now. I don't wanna jump to it.

C

Yeah, it's it's a good point. I'll, take it up up there.

C

um I just like kind of briefly like to to finish the the train of thought on the on the border router. um What we've? What we've tested in that on on the iot lab, is that um you, you can take it further.

C

You can even use the the individual nodes a lot in in a six load pound mesh as limited um as limited caches, and if they have those responses, they can serve them um that that leads to interesting effects on on the on the on the shape of the traffic in the sense of um how much data is there in the co-op header versus how much is there and six load pan header, um but it can be done and it gives it good results, at least in the, in the scenarios that we've been creating.

D

Have you tested it block wise? No, not yet.

C

So one one thing: um one thing that will so one one thing that will make this: um um how do I put that best? um One thing that will need a bit of exploration is um how this is bad best tradeoff between inner and outer block wise, um because one thing, because the the experiments have shown pretty clearly that um fragmentation is pretty bad and once you're over that threshold of the link layer and you you're in big trouble and I'm kind of feeling reaffirmed for having won that message.

C

Overhead kills a t-shirt for a few itf events.

C

um So if this is, if this is used for firmware updates over radio, you would probably have to find a good trade-off in terms of um inner versus outer clockwise in order to make up for the for the 64 bytes of signature that are on every outer block on every inner block.

D

C

In general it was, it was rather tricky to get both the the request tag that needs to have a certain length um and the signatures um into packages that will, in the end now fragment for the tests.

C

I mean it's kind of the signature is half the is half the mtu so.

D

Yeah right, so so, okay, so maybe fragmentation on other level would be more.

C

Yes, so if, if, if we transport, if if this is used for anything larger than kind of some very small data, then it's probably advisable to use out um to use out of fragmentation, to get down to the link layer mtu and to then use inner block wise for a same size of the same size of blocks say possibly 4k. Or so I mean if it's from where you have to put those that data somewhere anywhere, maybe 1k, maybe 4k, something that you can reasonably manage in a block-wise fashion.

D

That makes sense.

D

C

So um just michael are reading your comment on on jabber. I think the question of whether you're convinced that this is a problem that needs solving is has been addressed.

E

Well, um so it's not the only way to do uh uh uh some kind of caching of firmware updates, and so, if, if that's the killer app for it and there aren't any other use cases, then I might say well, maybe we actually should have a bespoke protocol for firmware updates um and uh there so at least at least that needs to go into section.

E

3.1 um carson asked a question earlier about uh doing requests against the sensor, and I I I I can imagine in this case the sensor is quote behind the proxy um and there's uh uh some number or a large number of um requesters in front of it, who you know it's sufficient. The temperature doesn't change more than every couple minutes um and you have a thousand. You know devices that want to know the temperature um yeah, maybe that that would make sense to me.

E

Yes, when the temperature does change that invalidates the cash and um you know they all get a new thing. um I think that somewhere, that should be contrasted, maybe to using observe uh this can be combined.

E

um Okay, but without the proxy. Do you get the same effects if you multicast and observe to all the listeners right? It's a different model. I good knowledge so.

C

The the thing is this: this has with with observation. This is multicast responses and multicast responses. What we've been doing originally and we'll probably still be doing, because this documentary is behind the other one- is to create the create uh to create a consensus request in a different way and have the server serve that consensus, request and kind of do some extra work to get to get where we get here for free, um and then we have an ongoing observation over which we can send out the notifications.

E

Okay, so I also hear that there's we need to have some text or another document that kind of compares and contrasts these different things such that um someone doesn't have to be an expert at all the different things in order to figure.

G

E

Which ones to use um I, I think that some more real world examples would be useful. A concern that I I have about in the should we do this at all um is how is this configured um such that it is enabled, and given that we have made some compromises in the os core properties um which we're not sure are safe or we may may be safe for certain circumstances and unsafe for other circumstances?

E

How can we be sure that a proxy and or respondent hasn't been tricked into doing this um by when they shouldn't have been right?.

C

There's I mean the proxy is always good to do whatever it wants, because it's not part of the group and it's an outsider for all for all purposes here anyway.

C

um As far as the server is concerned, there's two aspects to this one is that and that's one that a library can check mechanically, provided it's trusting its users to kind of use. It right is that this is only ever accepted for safe requests.

C

um So that's something that should not need much configuration because I get if if a get handler um has side effects, then that server might already be in some other kind of trouble.

C

um On the point from from the permissions point of view, um it's I think it would be, I think so that's I think it should um be generally safe for group situations as long as the deterministic client is given only the permissions that any member of the group automatically has from a practical point of view, without any shoots- or probably um this is something that that would be best to configure on a per resource basis um and possibly be advertised.

C

Advertising of course means that the client could again be tricked into doing this, so there might be additional, so there might be a configuration on both parts um that is necessary and yes, this does need further examples and um exploration.

A

On the permission part, I think the draft says already that the deterministic client has the minimum combo set of permissions of all members anyway. Yes,.

C

That's partially because um the because everything that is going into the encryption part is only um affecting the a uh the authenticated data of the response, so a group member that would not have the permissions could take and take a captured response and read data from out there.

C

Similar to that I mean this. This is really similar to the general case of of group security. Where, if you respond in group wise mode, then your response is public to the whole group, which is the reason why you have.

A

A

I think it was the last slide anyway. Yes,.

C

And it's already a lot of lot of good input for for the one which then probably won't happen this weekend.

D

Yeah great great work good to see it's progressing. Thank you and also the implementations. um That's I mean that's the driving force here and that's as as michael mentioned on on that. There is a reasonable, uh interesting application for this, and I I think I mean I like this technology, of course, but I think that it definitely makes sense to have.

D

um We haven't looked so much for the group scoring itself for for sort of the performance aspects there, but um but that that's that's another reason why.

D

Why that type of estimates are important? I.

C

Think yeah performance of group oscar hit me pretty hard when I, when I first set up everything for the test bed, because that was the first time I realized how expensive asymmetric cryptography still is I mean I don't. I don't even want to want to guess how much an rs a signature would take on on on an embedded device, um but even the software, even the software signature takes like a second or so, and this is all I mean this and group of co in general.

C

Now my opinion is only really feasible if you have hardware acceleration for the cryptography part for the for the asymmetric cryptography.

C

A

Okay, any more comments, feedback.

A

Okay, then we are done with this item, for today uh we have a lot of times pair. So is there anything more you wanted to raise than discuss today? Also other.

A

A

Take that as an o, so I think we can even close the meeting pretty earlier than planned and the next one in two weeks will be about downlinks with bill and alan. That promised to run the show yeah.

B

So one observation that is not directly related to core the sibo working group may be looking for a new chair.

B

B

So yeah, if you know someone or are someone who could do that, please talk to christian and all the ada about that.

F

Thanks carsten.

A

Okay, any more plans for today.

A

Okay, then we can close the meeting. Thank you all for attending and the feedback.

F

Thank you. Thank you. Thank you. Bye, bye, thank.

F