Internet Engineering Task Force Interim Meetings, 28 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CORE WG Interim Meeting, 2021-04-28

Description

CORE WG Interim Meeting, 2021-04-28

A

We are recording now so welcome everyone to this virtual interim meeting of the co-working group. uh This is marco.

B

A

My co-chair is um hi many minutes and we are going to have six interim meetings before itf 111 and you can see we are back on the on wednesdays.

A

So as usual, this is an officiality of meeting which is recorded, and the note 12 applies so be sure to get familiar with it if you're not- and this is not only about ipr- it's also about code of conduct. So please be nice with one another, and the agenda for today is about two related topics.

A

uh First john will present about limits of a deciphers and key usage with those ciphers in general and about how we should take this into accounting core, and then we have a separate presentation from from ricard related to the uh ongoing draft on how this should be especially handled in all score.

A

So anyone who wants to best the agenda for today now then we can uh move to the first topic.

A

Please francesca.

B

Yeah just wanted to mention that um the draft itf core new block um has finished last call and has been um or the ballot has been issued, so it will most likely go into um into next week's stellar chat and the other document that is waiting with me is the uh core sid 15 and I am waiting on casting and I think he mentioned that.

B

What's the status? No, I'm not. I don't have it in front of me.

C

The status was that we wanted to get a meeting going between the authors and and the shepherd, and maybe a couple more uh people, and that is still pending.

B

Okay, great, thank you.

A

Thank you so john floor is yours.

D

Thank you. So this is, if you use something official for the meeting material, take the second link later it has a new front page. The 80s complained that this was too much of a light lightly, dressed girl.

D

So that version has a traffic limit instead, but otherwise the content is the same, so we can use this uh so next slide. I think we can go through this quite quickly, just focusing on the high level recommendation from this.

D

So he has to fresh episode. There are q is the number of protected messages.

D

V is the number of forgery attempts I.e number of failed, aaa decryption, invocations approximately and then l is the maximum length of each message in blocks, so 128 bits or 16 bytes, and I completely agree with the analysis in tls and details that this is necessary. We should have this kind of counters, and we should re-key, then re-keying is maybe even more important is that we limit um the impact of key compromise, but compared to other limits where you have like you want to um avoid non reuse or something.

D

These are not very strict limits, so the limit set by tls and what oscor will set is quite arbitrary and very soft limits. If you go over them, everything will not break. You will get maybe two power 62 bits, 62-bit security instead of 63 or 64 or something, but it will slowly get worse next slide.

D

So, basically, what I think what we can do is we can. We can use a slight a better process for how could to calculate these um the numbers. So this slide is not about how the actual process will be in oscar, that's wreakage. This is how do we set numbers for the queue and the limits that richards dropped late will use. I think, some of the tls numbers we can relax enormously uh for ccm8 some other of the values we should maybe make a little bit stricter to make ccm 8 could be a perfect mac.

D

You can take.

D

D

So yeah, um we don't need to go through these mostly so I think you can you don't need any limit at all. It's basically a perfect prf. If you want to treat it the same way as a s, is a permutation, uh maybe important to keep in mind that the attacks you're protecting against here is very, very different. One is an online attack which, if it happens, have very drastic consequences you for a message.

D

The other is distinguishing which is offline, but on the other hand, it's like probably nothing happens. If the attacker can distinguish this, he can just to see that it's all score. He can just look at the port number or something and and see that so there's a it can be a quite large gap between this theoretical attack and something practical. Next.

D

D

I think we can move on since the ccm8 behaves quite a lot like the 60, perfect 64 bit mac, uh and also that limiting c advantage per key makes does not make very much sense in the security protocol, where you have multiple keys per connection, you can have mult, and you can have a lot of also connections between the same two peers, yeah.

D

D

It's quite easy: you don't need to do very much advanced calculations to see when it makes sense to re-key. If you have a linear function, you don't really get any benefits from re-keying directly. If it's quadratic things will get worse and worse and at some point you need to re-key can take the next think we can go back to these slides if there's something we need.

D

Yeah here it it's a second bullet here is that some of the values in tls we might want to make a bit stricter uh right now, ccm deviates also in the beginning from an ideal mac which we'll see in the graphs in the coming slides.

D

So we might want to lower q and l, and I think we can do that without any big consequences and the on the other hand, we can make very very large for cesium.

E

John uh something maybe worth clarifying what what track? What is the practical implication of lowering q and l.

D

So q is the number of produced messages with the same key and l is the length of the maximum message that you.

E

Allow so it's actually l that we are lowering compared to.

E

The tls computations right.

D

R and r it this slide suggests lowering q and l, um but we could also based on at least if it's not a problem doing so. If you do that, ccm behaves like a ideal mac also for low values of the.

E

D

There, but whether it's absolutely necessary to do that, I don't think you could also use the tls numbers and saying that you are as good as tls. I I don't think any of these is real, really essential. I think tls working group has been taking these numbers a little bit too serious.

E

Right but q and v appears later, but l l doesn't will not appear in recast document, for example. So I think the impact of lowering l needs to make it clear actually.

F

Yeah and will appear because it's part of the formulas- okay in the c4d document, so we assumed uh 1024 2 to the power of 10 as well. Okay, so if that lowers, it will change the results.

E

All right, good yeah.

D

Then I'm happy. Thank you. I think that needs to be probably been stated in richard's draft. Whatever value we decide to use next.

D

To here is just some first graphs: you can see how changing these parameters improves the security. If you lowers l on the left side on the right side, you can see how a suggestion the suggested process that I made, I think it seems better than the tls, but I only used it for a week so it but showing how you can measure the security level, and then you basically take the minimum y value of the graph from here 0 to 20, and then you draw a line and then you get your security level.

D

The attack will attack the weakest point here and on the lower left, you see some how it affects if you lower both l and q. um The next.

D

D

There's mostly theoretical that you actually can get depending on how you measure you can actually get lower security by.

D

With multi-key at least depending how you measure, if you measure security level, I think everything will be, then you will get the same again.

D

You can take the next slide.

E

D

John again, what's.

E

The practical aspect of multi-key is that you have multiple security associations between the same end points or, what's.

D

Yeah yeah, typically in in the academic literature, it's known as multi-user, because this type of attack started, I think, maybe with who was starred and some attack paper on rsa, and then it was assumed that each user has one key.

D

um So therefore it in the academic literature is known as single user single multi-user, but in reality it's just one or more keys. The attacker attack one of many keys or it attacks a single key.

D

It doesn't really matter who wounds the key or if one person owns many keys.

D

Okay, but if you have, if you do re-key and then the single oscar tls dtls connection is multi-key.

E

D

Next slide, I think this is maybe the most relevant here. This slide comes to completely different conclusions than the tls process, which I think is flawed.

D

So on the left side, you see the um security level here on or it's actually not the security. The security level is the minimum of these. It's rather complexity uh for here for different values of the, but, as you can see, the green line is a perfect 64-bit mac and the blue line is ccm. The blue curve is ccm8 and, as we can see, it deviates a little bit from a perfect mac in the beginning and you actually get only 60 bits.

D

But if you lower lnq a little bit, then it behaves like a perfect mac uh until almost two to the power of 40, at least to the power 35 or something so we can definitely and ccm8 is not worse than ccm with a full mac in this aspect.

D

It's rather it's can't say it's better, but it's it's much closer to a 64-bit mac. Then the full ccm is close to 128-bit, perfect mac.

D

So as long as you're fine with 64-bit security for forger, which I definitely think is not a problem at all, yes, an attacker trying this on a lot of constrained ot would take.

D

I don't remember, I did some calculation, maybe on the next slide, it's a long time. Basically, you don't need to be concerned.

C

As long as you take this offline, it's online sorry.

D

Yeah yeah: this is an online attack. Yeah.

D

D

D

So yeah, I think we all here we can see you need to to 64-bit tag. You need 4.3 billion messages per second for 68 years.

D

That's quite a lot.

D

So I think that's not the problem. Ccm8 is basically a perfect mac, so basically, I think my recommendation would be to basically use take the tls, the tls values. The process is a bit flawed, but most of the values they get out are quite reasonably anyway, except for ccm8. I think we can take the tls values. We can use a much much much higher v value for ccm8 should, as we will probably mostly use ccm8.

D

We should maybe consider lowering the q and l value for to then we can then we, the analysis is that ccm8 is almost a perfect mac for all the values we will use.

D

Otherwise I don't know what is easiest when we discuss this last time with and christian had some idea that it was to allow easy implementation, they should be.

D

Q and e should be similar or something I don't remember the details of this, but um I think there's a lot of um whatever issues will be quite arbitrary to some degree. At least it's whatever you choose will be based on a lot of assumption, and I think, as long as we choose anything in this range, it will be very, very secure.

F

Just one question: so we can definitely lower the l value in the this score id limits document. As far as lowering the queue, I guess the q is the output from the formula, so the the way to lower it would be to reconsider these probabilities.

F

I think you mentioned those in an earlier slide where you had these boxes.

F

I think you should.

D

Not consider these probabilities at all. The conclusion from this is that the tls process makes no sense.

F

So we should not consider those probabilities. We should rather consider some other probabilities.

D

I don't think probabilities makes much sense, except for maybe four durian you have then it's very clear what the probability means.

D

I don't know, I think it's inventing it. The process will probably not go. I would say that we, my suggestion, would be that we take the tls values and lower them, and then we can at least say we are more secure than tls. Unless we want to, I think, as long as we choose lower or equal values as tls, we don't need to be justify it very much.

F

Right so so we would use lower for q and lower for l, but for b I guess we would end up with the higher than the what it is currently which is uh like 2 to the power 7 or 112.

D

Yeah, I don't think that's uh probably. I think we can motivate that with this slide set and presentation.

E

E

So this would be um so sort of outlining this and motivating this would go into security considerations in ricketts, often.

F

Yeah yeah, we could definitely mention their lower l and yes, one final thought is that you said earlier: we shouldn't consider probabilities but to use these formulas from the c4d document, we would need to decide on some probability, p, values and if we don't take them from dtls, we would need to motivate or take them from some other place or justify them ourselves.

D

No, not really, I don't think you should do any probabilities whatsoever. What I suggest here is that you choose a security level, which is a much more neutral thing to do.

F

um Okay, so you're saying basically to not fundamentally not use those formulas from the c4g document.

D

I think the formulas are correct, but the process how you get any limits from this formula formulas is, is very flawed and very arbitrary.

F

Right but if we don't have those formulas to rely on you're saying we should just like state certain limits ourselves.

D

What I, what you could do, if you want to invest in doing a process, would be to, for example, to use the inner qualities in the cfrd document. These are. These are correct, but they're still like inequalities. This is they.

D

They are not tight equations. There are inequalities, you could use these and then you can calculate the security level if, if you want and motivate it that way, but.

F

Right could could you go back to slide two or three, maybe.

D

I would but I or personally I don't think it's yeah yeah. I don't think it's worth the effort to to do that. I would just pick some values that are equal or lower than tls and write that we are more secure than tls at least, and then severely higher the ccmb value and motivate this with this slide set.

F

Right, so we can. We pick a lower value for for q, but for we we we do want to pick a higher value. Basically, and here we have to then motivate why we pick that.

D

I don't know if there's any implementation aspects of the one one way would be to pick like 2 to the power of 20, for both q and v for all algorithms, for example, or something like that. Yeah.

F

Right then, it's just about how do we? How do we justify for q because it's lower, I mean then that's easy to justify, like you said, we're doing, taking a safer limit here for we for we, it would be lower, except for ccm8 right where we would then choose a higher limit yeah the formula skip, so that would be the important thing to motivate.

D

I think you can just motivate that the tls process is wrong and ccm8 behaves like a perfect 64-bit mac until way way way higher than 2 power. 20.

F

Right and then the the place to put attack would basically in this in this draft in this uh score, aad limits uh draft.

D

Yeah, that would be my suggestion not spend much time at all in inventing, and I I think the process in this document is better than the tls process, but I don't know if it's I was not planning to to document it more than this. I'm not sure it's worth the effort.

D

I don't know what the cfrd group will do. I will object to the current process being published. I think.

F

Right because then they may right, if you object to that, they can take that feedback into account, and maybe they will change that document and we we still refer to that to some extent. So of course, we should see how that develops.

D

I think motivation is, it seems to be agreement about this presentation in song, so I don't think we will get any problems. I think everybody agrees that the tls process is quite flawed.

F

Right well, okay, then um yeah. I would definitely appreciate your uh input also on how to formulate this text to motivate the uh the iv limit. So maybe we can afford discussions on that. Yeah.

D

Sure I can I can do some. I can do a pull request to the draft. If you want.

G

Yeah, that would be yeah very nice.

A

John one question about raising v: um how can you we motivate that it has been raised enough.

A

Wasn't that exactly what we discussed? Well, we discussed to to raise it to some value that is good enough and make sense. But how do you motivate that the new value makes sense, and this good enough in general, just wondering uh the previous slide.

D

On this there, it paves it's very easy to see that this behaves extremely close to a perfect mac until 2 power 35 at least.

A

F

Right, I think that's the core core aspect and will be to to motivate that raising of the v value, because everything else we're actually lowering compared to the outputs on the c4g.

F

D

Yeah, I think these values will probably see if audi values will probably change. I I hope that the formulas inequalities is correct, but any values they get out. This, I don't know see if audio document talk a little bit about the process and then it talks a little bit about the values that tls and dtls has chosen, but yeah.

F

Right- and we should also check just by lowering and what impact that has in the first place on the v limit right here, ccm8. What the new result would be from that yeah.

D

But I don't know, I think the important thing is to I think I definitely spend we have already spent way way too much time on this. I think important thing more imp. This is not really security.

D

It's important to to re-key before you get extremely high numbers here, but otherwise it's um there's much more important security things to do this is this has been blown out of proportion, yeah yeah, I don't know. I think I think the implementation aspect, like christian wrote up last time, is there anything, but what would tutor power of 20 or 2 to the power 23 mean? Is there will be a difference in practice and also message? Length is very different for the application.

D

Also note that tls does simplification, assuming that all the messages are like max maximum length.

D

A

Okay and definitely if you can provide some early text with the pull request, it would be great.

D

I think I can do that after we have decided on some numbers. I think that's a easy writing. That is five minutes work for me and it's easy, but I think core group needs to decide on what what number should we choose? I think that's. That's mostly not a security question, it's more implementation and what does it? How will it impact applications using or score if we choose different numbers.

F

Right and reducing l would also limit. Then the maximum message size allowed.

F

Then would be 256 bytes for l2 to power, 8.

A

Okay, any opinion from the group any more input to this early implementation. Consideration.

A

Okay, then we take this as a start, including the number suggested here. I think that's a good start anyway,.

F

A

Okay, if there's nothing more to add on this particular item, we can move to the next one.

E

Marco, do we need did do we need to have an offline discussion on on this on these choices here or is it a mail thread, or how do you see that we progress on a mail trade on the list? Would work.

F

I think yeah that can make sense to start the discussion, then, based on the some numbers here proposed in the slides and initiate some discussion, see what feedback comes on, that yeah.

D

Yeah, I remember christian, had some some ideas. What he.

F

Wanted yeah, he may have some some feedback.

A

We take this also to the list, then.

F

A

uh Moving on then, the follow-up to this and more practical to a draft considering this is a starting point for allscore. So just tell me when to change slide record.

F

Right right, so this is a presentation on this draft about this aad key use its limits in the context of all score next slide. Please so just to recap the problem, which of course has been recapped a bit already, but now score uses aed algorithms to provide security, and there are these forgery attacks against aad algorithms, and this is described in that c4d document.

F

That's referred there and the problem is that adversaries may break the security properties of the aad algorithm, and this draft will focus on the aad limits and their impact on all score, and that includes first yeah, like defining appropriate limits for all score.

F

um As we discussed, it may be the case that I'll score shouldn't just blindly take the the formulas and limits described in the cpg document, um and the second step is uh how does this for their attack and the limits affect those core um that can be in terms of what steps you need to take during message: processing, for instance, counting, send messages or receive messages, and what actions should you take when the limits are exceeded?

F

That can be re-keying the context so next time, please.

F

Sorry, here's some background noise there, some construction here, but so basically, what do you need to count?

F

So the q value represents the number of messages protected with the specific key meaning the number of times it keeps being used to encrypt data, and the v value is that the number of 40 attempts made against a specific key meaning the amount of failed encryptions for that key and in the context of oscore what this means is and what we have added to those core security contexts for uh these new parameters, and one is count q to count the number of times a sender key has been used, encryption count v to count the number of times the recipient key has been used for failed decryption and both of these counters then have associated limits, limit q and limit we, which will eliminate how high these counters may go and if the limits exceeded now the context must be repeated, and this draft also has an overview of existing methods for keying of score.

F

That could be used and currently again, like the the values and the calculations we have in this document. Currently is that's based on the c4d document and then the probabilities that was chosen from dtls.

F

That's secured material next slide, please and now going over some updates since itf 110, and this material is also in the available in the editor's copy of the draft in the gitlab repo.

F

So one thing that was added was a table with the qmv limits for further algorithms, um aes, also aes 128, ccm, 128 gcm to fix 256, gcm and the charge up only and before we only had the aes, 128, ccm8 and, of course, like these. These values are still based on that c4d document and the assumptions from dtls, and in addition to that, we have extended a section about methods for all scoring keying.

F

So now it also mentions previously mentioned the the ace oscar profile hoc um and, like manual uh key update, let's say and those core appendix p2. Now it also mentions that you may as an alternative, if you're using lightweight m2m- and this is a situation where you have a five return term server and lightweight m2m client.

F

You may uh bootstrap the client make bootstrap again towards the lightweight bootstrap server, which will provide it with updated security context if the material on the bootstrap server was actually updated and both like the temp time, client and the lightweight server may initiate this bootstrapping procedure.

F

Either client takes initiative to bootstrap on its own, but it's also possible for the server to tell the client to go on bootstrap, so in either case, if one of them gets close to reaching these limits or exceeding the limits.

F

If it's the client, it can bootstrap on its own. If it's a server, it can tell the client like please go on bootstrap um yeah next slide.

F

Please and another update that I was stating is fact that messages that are detected as replays do not affect the count b value, um and this is also something that was brought up by the previous in three men. We got agreement on this point that, since these are fundamentally replayed messages, they should not be counted as failed decryptions, so they will not affect the county parameter.

F

Another point was adding this expiration time stamp on the score security context, so it's basically an integer integer value, similar to a unix timestamp.

F

That indicates at which point in time, oscar security context may not be used anymore for processing messages, and the idea is that when the context is established, you you take the current time and you take a certain time offset that should be the lifetime, and then you can calculate your expiration time step and when that is reached, you should not use this context any further and the last point was kind of general editorial improvements. Some restructuring fixing some some sentences and general improvements.

F

Yeah next slide. Please.

F

And then we come to the open points, so the first one is: what should the default lifetime be of an oscar security context, because now we have this expiration parameter that is set when installing the security context, which basically is the current point in time plus this lifetime.

F

And if the lifetime is not provided from elsewhere, it could possibly provide it from from other sources like if you're using ad hoc. It may be some pre-configuration there in the applicability statement or there could be other ways to set this up.

F

But if you don't have an actual lifetime defined or is not provided there should be an appropriate default lifetime to use and by the way, also the lifetimes and this expiration date and time they don't have to match on the players, because if one has a shorter expiration or shorter lifetime, the one that reaches the expiration first will simply take the initiative to rekey with other party. So they don't have to synchronize on exactly the same values, but there would be um a need to choose some appropriate default if none is provided.

F

So that's one open point.

D

I think you should clarify what the lifetime of a security context.

D

That's do you mean security lifetime of a key here.

F

Yeah the live, I mean the lifetime of the keys in the context, basically so that when you reach this limit you you need to rekey the context yeah yeah. I can open that.

F

Right and then the second point there was that we need to consider how to make the the count v and count q parameters work well for constrained devices.

F

I mean the case that a constraint device supports appendix p2, meaning it stores its sender sequence number to be able to reboot and then continue using the same context. It now also needs to store the account v and count q as to not lose track of them upon reboot, and so the pointer would be to allow save continued usage of uh score security context after reboot and in appendix v1. There is the solution to not store every sender sequence number.

F

You only store it periodically to reduce the number of writes to non-volatile memory, and this would be a similar situation where you don't want to store every account q and count v, because then you're really writing a lot to the disk. You only want to store them periodically, but still make sure that you have them still available after reboot.

F

But the thing is here that we need to consider what rate to store this at, because if the rate is too large, uh then when you reboot- let's say you, you save every 100, can't we. That means that if you or account we won and then you reboot, you jump all the way to country 100 and if the v limit is quite low, as we are now in the current figures. Of course, that will change, but then a reboot or even two reboots would put you over the current limit.

F

So um you need to be a bit careful on the on the rates that are decided for often to store these values, especially for count b.

D

Have we decided that storing these numbers is that the only solution feels like you can also have some idea where you reboot your re-key as soon.

F

As you reboot, that's true yeah, definitely like you can have that choice. Let's say you don't even support appendix b1 or you simply say that. Well, if I reboot either way, I will lose the sender sequence number um you can choose to reboot. Sorry, you can choose to re-key if you reboot, so it's not mandatory in our citations is just that. If you want to support appendix p1 and be able to conne continue using your security context from where you left off, then you also need to say count. Q and count v.

C

So count the accounts that you save are essentially a limit up, to which you can just use new numbers without storing that.

C

So if you actually have a clock and can rely on that, then you don't have to have these things constant.

C

You can actually do a simple linear formula for the number count that should be applying at the time a reboot actually happens, and as long as you stay below that line, uh you don't have to store anything so that that would mean again as as long as you have a real clock. You can rely on at the level of security considerations, but if, if you can can draw this line, then you essentially never have to save the counts.

F

You mean you base the count depending on the time or you, but it's not certain. The count will grow linearly with time.

C

F

C

It grows beyond the line that you have been drawing. Then you have to store.

F

Okay, that that may be something to explore. I need to understand it a bit better but you're saying basically to utilize the effect. I think.

C

That that works much better if you make a few drawings, but it's an obvious way to extend the scheme out of rfc 8630 and take into account that most applications have a rough idea of the the the number of messages uh that will be sent and of the um rough lifetime.

C

uh The the device will work under, so you can actually choose a constant and a linear factor and and use that, but again it only works. If you have a reliable clock, yeah.

D

I think we should allow many different implementation of of this, but I guess that's the probably the suggestion to here to have this in appendix more guidance. This is how you can recover.

F

Yeah, the initial idea we had was this kind of rate. You save every 50 countries, for instance, but of course this could be a more flexible if we want to allow more more freedom for implementations within more clever ways.

D

Yeah, but I guess like in auschwitz, saving every every end, it's just a suggestion for an implementation. This is one way you can do it. The only mandatory is that you, you must not exceed the limit queue and limit the. How you make sure to not do that is up to the implementation.

C

So the main point of actually recording these things in the draft is to make sure that people know that this can be done and other people can't go ahead. Patenting the obvious schemes yeah. I think it's.

D

Great to document these things and give guidance, it's also good. It's not trivial to come up with these things, and so they work. So it's very good if we can give guidance also.

F

Right yeah, it can be implication, implementation guidelines, so people that don't miss this end point let's say and then an idea on how one way to do it, which would be this uh saving every end. Yeah.

E

So carson just to understand your idea, are you saying, with my words, then you're saying that basically we have an application, has an idea, a number of messages per per uh the maximum number of measures that can be processed in in a certain time interval. Then you draw the line and sort of align slightly below that, and and and that means that you will uh you will always um I mean if you don't even reach up to that line, then you then you don't need to store. The count. Is that something like that.

C

Yeah the the idea is that what you save in in these storage locations allows you to have a safe assumption uh for continuing after a reboot, uh so what whatever you can can save there that allows you to derive such an assumption at a reboot is fine as long as the the implementation that actually counts remembers that uh it needs to be on the safe side of that line.

C

That makes sense to me.

F

Good thanks all right thanks for the input um yeah next slide, please.

F

Next slide and see it update yet.

F

Hello, can you still hear me.

E

Here you record, but I don't see any progress on the slides.

D

A

Maybe some technical problems now I should back again right hello.

A

Yeah I lost the last two or three minutes: okay,.

F

A

It was kicked out of webex altogether.

F

Right yeah, we we wonder what happened but assume some technical issues, yeah.

A

Do you see the slides still by the way.

F

A

Yeah well great.

F

A

F

Resumption works. Fine, please go ahead. Yes, I was just saying thanking everyone for the for the feedback on these points and the next slide. Please.

F

Right and then another point is to further explore optimizations for tracking count q, and um this can again be helpful for constrained devices that this would be in general on how to to keep track of q. Basically, so that one idea could be that you don't have an explicit count. Q parameter, but you instead rely on the sender sequence number, so one one example is using the center sequence number together with this x, where x would be the amount of the number of outgoing messages you sent without partial led.

F

So, basically, the ssm plus x would be the same as count q, so they don't need an explicit cap q variable. So you can save some memory overhead, thereby cleverly reusing the ssn. Also for this, and then another possibility would be that you rely only on the sender sequence number, and here we have some.

F

They have some backup slides on this point also, but basically you would then, in that case, sacrifice some accuracy and accept more frequent rekeyings, because you may end up in a situation where you don't go all the way up until the full theoretical limit you could have gone to, but we can come back to that if we cover the backup, slides and then yeah. Another point here was: if these limits kill this, could they possibly be defined in a more general location?

F

um Of course they can be defined now in this, this osc limits drafts, but if they are for algorithm specific, um then they could possibly be defined in some place, like the cosi algorithms registry, uh although as we've discussed now, maybe this would be. This limit would be, in this case specific to score, and then in that case it makes more sense to keep them all in this.

F

Document um and then the last point here was yeah how to adapt these limits to be more uh specific and suitable for all score, and there one point was this: like: should we, for instance, consider different probabilities, pq and pv, and I understood from yeon that he thought that wasn't something we should consider. Basically, we shouldn't really consider these these probabilities or to plug them into those formulas from the c4d document.

F

And the other points would be like if we now can see the different limits for all score, what kind of authoritative and appropriate reference to use to produce these these numbers like that could either be. If now the c4d document will be updated, um it could be some other source or, as we discussed earlier, it could also end up that we justify and describe why we chose these numbers in this actual draft.

F

And yeah, the last point, of course, is synchronizing with john on this, and we could discuss more with him and like he, he said he could make some bullet requests and then we can start putting together the text on how to justify these limits for a spiral score.

F

Right yeah next slide. Please.

F

Yeah, that's the end of the regular slides. There are some backups too, but any questions at this.

F

D

uh No question high level what I think the two aspect that I think is important for the group to discuss and which we have so far not discussed a single minute. This meeting is what how does different limit affect applications and, secondly, how do we do re-keying?

D

um How do you, how do you do lightweight re-keying, with or without not resetting the sequence numbers, and how do you do re-keying, so you get uh forward secrecy.

F

Right, yeah and now now in this draft, it's it, it only describes existing methods for a keying. um Of course, the ad dock is a good one there. If you want forward secrecy, but um did you have in mind some, let's say some new method for a key.

D

Yeah, that was what we discussed some earlier interview meeting, I think or hackathon.

E

I think we said we should produce another draft which, which is looking at key updates and describing different alternatives.

F

Yes, we are called, we had those discussions and we we continued some discussions on that also so that yeah, that would be definitely a then a suitable thing for a and a new draft yeah.

D

Why would you have a new draw like putting these numbers like they needed to have these 80 limits and yeah state that you need to be keying that amount to takes for that is minimal?.

F

Right I mean yeah, I think. As far as I recall earlier discussions, we kind of had this idea of splitting things like this would be the first draft. Then there could be a follow-up about new methods, free keying, but I guess there could also be something to reconsider and add more material to this current draft.

D

I don't think this draft works unless you know how to do frequent, rekeying.

F

Yeah yeah, but it does, I mean it does describe the existing methods, so you have, um I think, it's well fundamentally, for which would be the yeah, the asos core profile, ad hoc or score appendix p2, the current uh incarnation of it or then also like to attempt to impossibility, or as a fifth one manually, changing the the context information.

F

So there are existing ways but sure there is room for the same, improved or updated the score appendix p2.

E

If I understand you're right john, what you're saying is that if we have another draft which describes different ways of updating the keys and that would sort of be dependent on this one, so we would what is written currently in this draft would need to be updated, so they are somehow closely linked to each other yeah. I I don't I don't mind if we expand this on this draft in this direction. I don't know if there is.

D

I think yes point: these are the two things I was hoping to get from the meeting today. I think these are the two things that are important to discuss.

F

Yeah I mean we did have plans to.

D

I'm not explaining these limits are, or are extreme, very needed, but it's like it's um it's quite obviously how to make them. I think I, my presentation is not very important just showing that the tls process is is very flawed.

F

Right right, yeah, we did our plans to to basically start a new draft on oscar keying and update the methods for us cory, king as a separate one, but if people feel that this would fit better in this draft already, that's certainly a possibility.

D

I I don't know, I just feel that that's probably more more urgent, more gentle than prioritize them.

A

But john, you seem to have a preference for a single document covering the numbers and keeping track of them and the procedure.

A

Does anyone have any strong idea in favor or.

A

Against otherwise, we can start building on your preference on that.

F

Yeah that should work.

F

It's fine with me to add that additional material to this draft and then the title may be changed a bit and to make it more general both describing these limits and also then, a new method for for a key moscow which ideally then gives perfect for a secrecy and nice security properties based on the current appendix v2, most likely.

A

Thanks for the input, john, and if there are no more input on this, uh I think rickard. You mentioned some backup slides on that particular point on the optimization uh we may go through them.

F

Yes, we could certainly do that. um I noticed john mentioned also how the limits affect the applications, but I think I can go through the backup slides.

F

Then it shouldn't take too long, just two slides okay, so this is describing a possible optimization for the count q to keeping track of count q without explicitly having a count. Q parameter in those contexts- and one drawback of this would be that you basically have a pessimistic overestimation. So you overestimate the actual value of count q.

F

It will be higher than if you had an explicit counter, so you may end up breaking earlier than need to be, and the point is that basically like at any point in time, you know that an end point, the maximum number of encryptions- it's it has done- is its own sender, sequence, number uh added with the sender sequence number of the other endpoint, uh because the other endpoints and the sequence number can serve as an overestimation of the responses without partial av that us. You know the december test, um yeah.

E

Next slide, please sorry, is this sorry, this is from the point of view of of the client or who is counting here.

F

Yeah, in this case, it will be the point of view of the client. Yes, okay, uh it it. It goes into for the details in the next slide. Actually, yes, uh so here it's more more defined. So, basically before performing an encryption, an endpoint stops and invalidates the security context.

F

If your sender, sequence, number plus x, exceeds limit q, so basically the count q will be represented as the standard sequence number plus x, um and we in this case you determine x in the two of uh the following one of the following two ways: uh if you're producing an outcome response x would be the partial v in the request you're responding to so basically x is kind of a standing them for the other part to send the sequence number right, which would be the partial iv and the request it has just sent to you and and back to your pointer.

F

I mean this could work uh regardless. Actually, if you're a client or server it's just, it works in either case. Okay and um on the other hand, if you're producing an outcome request, then x would be the highest partial portion of e value that you have received in your replay window or the wrinkly window. Size minus one if you have not received any messages yet um so basically x in the case of producing an outcome request, would be the highest portion of eu seen from the other party, meaning the highest sender sequence number.

F

So, essentially, what you're doing is x with extra estimating the other part you send the sequence number and you're adding that to your own and, as we saw in the last slide, basically, you know that you can't have done more encryptions than your, your and other 40 center sequence numbers combined.

F

So if you follow that rule, you know you will be safe. On the other hand, you may you may end up overestimating the the the count q and then re-keying before you actually reach the um the limit q. Basically, the actual limit q, because you're just estimating calcul you're overestimating how q, by using this uh method,.

E

But the overestimate is factor two right or what's or what? How large is the overestimate? How large can the overestimation be.

F

um Yeah, I believe it could be, it depends I guess it could be. It depends on the message pattern. Let's say: if you're, um I think yes, it makes sense the highest it could be would be to um like two times over estimation. uh Of course it depends. Let's say you, you send one request, and the other party sends you tons of notifications or it could be you're sending tons of requests and the other party is not even responding at all. It depends on the traffic pattern, but yeah.

F

I believe, you're right that the maximum or estimation you may reach is twice two times the size of the actual account you.

E

So that would correspond to one power of. In I mean we are talking about the two twenty or two twenty one that will sort of be one.

F

Yeah yeah one one, two, two power of uh yeah: I see a point right, yeah um yeah, so that may, depending on the traffic pattern or depending on your actual setup, that may not be a nice overestimation. On the other hand, if you use this optimization, you save the need to have an explicit count: q parameter, you can use the ssn, which saves the memory overhead, and I also recall in in some earlier meetings we discussed with christian on some some ideas.

F

He had on other possible ways of optimization, and this is a this- is based on his suggestion. um But I recall he also had some input on this. We should discuss further with him, but there could be room for for this kind of optimizations for reduced memory overhead in the counting procedure.

F

Yes, those are two two backup slides prepared.

A

Thank you any more comment, questions for rickard.

A

Okay, trying to sum up so we got some good input from from john on new, better numbers to use here as more appropriate. So we can build on that as actual numbers and on security consideration. But we are going to have a thread on the list to discuss that more and there are feedback to address some of these points and and the one on rebuilding on appendix b1 uh of oscar can actually be further expanded.

A

And then we say we can actually take the path where uh a broader draft can cover both uh this topic and the possible actual uh lightweight working approach.

A

And I know you also like to have more discussion on how applications are affected by this. uh I suppose you mean both the numbers and the lightweight working procedure.

D

Yeah, I think lightweight the requiem procedures is basically required. If you want to do re frequent freaking, I think you you want to do that built for the basically equally much because of the aad limits, but also to get forward secret c, which is very quickly becoming best practice. To always do the feedback. I think we should consider whether we should use how much should be. Should we use to the power of 23, or should we use different values for all the algoriths?

D

Is it easier to use 2 to the power 23 for all of them? Does it matter if you have 2 to the power 20 or to the power of 23 or 22 or 21, and does the message size matters much? Is there applications that want to send 2 to the power of 10 instead of 2 to the power of 9 or 2 to the power of 8.

A

Your question, your question: does, it matter is refer to the application on to the security.

D

Yeah exactly completely this question is completely non-security. I think the non-security discussions are much more important to have.

F

Right right, how they exactly misaffect applications, yeah.

D

I can make new growth for ccm8 how how different values of q and l makes it deviate more or less from medial mac could be and what security level you get in the beginning.

F

D

But I think it's important to find out is this: like? Is this limiting for for applications.

F

Yeah I mean right so, but the implication for the applications would be yeah more more frequently keying, basically and okay.

D

F

Messages exactly right, reducing that could be again like if you reduce that to the power of 8. You end up with 256 bytes.

D

F

Okay, 256 blocks; okay,.

D

Yeah, so it's not so limiting, but if, if 2356 blocks is limiting, then you might consider two to the power of nine or to the power of ten and maybe lower q, and you can also make something a little slightly more complex and tls, and not just assume that all the messages have the maximum size.

D

But then, of course, you you get complexity in the application. Yes, the most exact approach would be to actually like calculate the length of all some up, some the length of all the messages and use. That is that just n times the maximum allowed size, but that's probably not something we want to do.

A

F

Yeah, thank you for input.

A

Any more comments or questions.

A

You know we are on the any other business anything else you wanted to raise today about core.

A

That's also another. No then we can adjourn the meeting a little earlier than the official end time and talk to you latest at the next one in two weeks.

A

It's good. Thank you all see you. Thank you. Thank.

A