Internet Engineering Task Force Interim Meetings, 18 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: LAKE WG Interim Meeting, 2020-12-18

Description

LAKE WG Interim Meeting, 2020-12-18

A

B

So hello, everyone, this is the lake working group virtual interim meeting. uh My name is malisha wuchenik and my co-chair is steven farrell stephen. Can you hear us.

C

I can hear you fine, thank you.

B

Okay, great so uh essentially, we have two hours allocated today. We have uh michael richardson and euron salander volunteering tonight to know uh to do the note taking. Thank you both for this.

B

uh Before we start, I would like to remind you that uh this is an itf meeting and the note well applies just as for any other itf meeting, uh most notably if you're aware of any patient patterns, uh please do disclose them or do not participate in the discussion.

B

uh So on the agenda today, uh we uh we have uh the remaining discussion about the open issues uh from the ipf 109 meeting. That john will lead and we will prioritize this item on the agenda in order to uh to resolve as many issues as possible. uh We have uh we have a report coming from francesca.

B

Regarding the echo interrupt testing that happened uh last week, I believe- and then uh I opened for uh for bashing this agenda. We received uh one request from renee strike. uh Renee are you there.

D

uh Yes, good morning, good afternoon,.

B

Yes, so you would like to discuss uh essentially the elliptic curve, cypher suit, lightweight type of suit. uh Is that correct.

D

uh That's correct, so I prepared uh two or three slides and I think it would be able to uh provide a potential solution for some overstanding issues on uh um slide 14 to 17. I believe, okay,.

B

So would it make sense to discuss this address after slide? 17 of the issues.

D

uh That could be done uh as long as we don't rehash a discussion. I could also just put those two slides on and then you you can bury the mind for the other discussion up to you.

B

Yeah, so I would prefer to prioritize the issues and then essentially because uh your slides to my understanding refer to uh the last issue, which is the mti suit. So uh let's not make any decisions on that before you present. Your slides is that is that okay, perfect, all right perfect. So, let's write add, let's add in the agenda for any strike after the issues for 10 minutes uh for 10 minutes and then we'll have any other business at the end.

B

So that concludes the chair slide uh and the first item on the agenda is, I.

C

Guess military we should just check. Is there any other agenda bash people want to do, or is that oh yeah yeah.

B

Is everything everyone with this agenda.

C

Okay, it seems so, and I presume in the any other business we can discuss whether another interim meeting prior to the next ietf is useful. So we can do that at the end. So.

E

Okay sounds good and then how many slides we, how many issues we close right exactly.

B

Okay, so the first item on the agenda, then, is uh john uh with the issues on ad hoc john. Can you hear us? Yes, can you hear me? Yes, we hear you very well. I will mute and the floor is yours. Just let me know when you want me to switch the flight yeah.

F

Thank you, so this presentation will go through all the remaining issues. I will also shortly tell you what has happened with the issues that was discussed at the last itf meeting and also, I think some of them needs some further discussion.

F

uh So with this, some of these issues have been implemented in in the document and we submitted 0 3 earlier today, which also have some other editorial changes so next slide.

F

uh So this is updates of the issues that we discussed at the last meeting. I also sent out this is basically the same text as I sent out on the list so resumption, nothing to do agreement and negotiating of parameters. Here we have added uh a new appendix it's around one page that describes everything that needs to be agreed between the initiator and the responder, and this was based on a suggestion by michael richardson.

F

I think michael might have been part of helping writing this also, but I'm not sure there is also some. Currently there is an overlap between the appendix and the section. I think it's now called communication protocol features that needs to be addressed in the next version.

F

Then we had an issue on identifying certificates and appears- and here there has been quite a lot of discussion in the course working group. There is ongoing thread how to identify a certificate with a kid and also there's been a request offline to add receiver certificates to the ad hoc test vectors, uh so the zebra certificate zebra certificate draws currently lack a private key to enable this, but this will be added, and then this will be added to the add-on test. Vectors on github.

F

We have also added it was a bit. I presented the issue badly last time and now in 0 three, there is new text on why the sigma protocol thinks that you need to mack the identity that is related to the public key.

F

There is now some text on that in zero, three and also yeah on on which things it mitigates. There is also an ongoing discussion with the certificate drafting cosi, which is related to this. That's not about identities, but it's of binding the wrong information to the public key.

F

uh I think this might be something we need to come back to in the future, but not now, unless anybody has a wish to do so, then distinguish error message.

F

So there was a request last time that we added text on how to distinguish an error message. This has now been done, but this issue has spawned several new discussions on github marco has asked and provided an answer for how to distinguish message, one from message: three. This seems to be more implementation guidance, but maybe there's some something test also needs to be explained stricter in the draft.

F

uh Then there has been a request from I've forgot from who, but to right now the error messages in ad hoc or undefined text string that application can set to whatever they want, except for the list of cipher suits. The list of cypher suits can be automatically acted on, but everything else is cannot, and it's also not standardized. So there's a discussion on github. Whether ad hoc needs to provide standardized uh error messages in the form of strings or integers.

G

John, yes, maybe we can open up for for some discussion here on on both these items.

F

G

So perhaps marco wants to say something about uh distinguishing error messages. The second okay, the first bullet was from our code. The first sabbat bullet on issue. 30 was from marco and the second one was from stefan ristisol, who is not here, so I don't think he will be able to provide more than on the issue. But marco maybe has something to say about distinguishing error messages, or someone else may have some input on on what we need to specify here.

H

uh Hi, marco, here just added one more comment on the github: it's definitely implementation guidance. I don't think there's anything big to fix in the in the protocol itself. It's just that. There's a lot of flexibility in in the roles that you client, server or reversed can take. uh They can have multiple ongoing adult executions and it's just important, I think, and simplifying to understand what exact message it is when received before starting anything else.

G

I'm trying to understand why they would have multiple I mean they could have. I see, but but is there a use case for for multiple, uh multiple ad hoc sessions in parallel.

H

If that's not required, then it simplifies things a lot and probably is just sufficient to understand it's error or not.

F

Yeah, but basically what you once did then, is to distinguish message, one and message: three, I I don't remember which solution you specified.

H

One q3 is just that you can have an ambiguity between two and three. uh If they have. I guess four elements in the sequence.

F

Yeah my understanding of how it should be what the draft said is that you use a connection identifier if the underlying transport does not provide a correlation.

F

Wouldn't that solve the problem or is there still ambiguity or are you using without the connection identifiers.

H

Right now, I'm using correlation mode one and the client as initiator initiator, it's all fine. In the general case, I get a message: it's not an error. What should I do now?

H

If, in general I was initiate a responder shouldn't? I understand exactly what message type it is before possibly retrieving an ongoing session, especially if I have many, because I was also thinking of that honestly.

F

I

You should understand from from from the correlations like this is a response, so you can correlate to the request, which means that you can correlate to which to the message like you can okay. This is a message too, because it's a response to message: one example: if you're using co-op, that would be using the token the co-op token.

H

What if the initiator is a server.

I

Then you're using connection identifiers. That's what, therefore that's what john was saying.

H

We need to understand what message it is to understand where to take that identifier from from the message again, of course,.

I

I mean you're gonna have one more element in the sequence right and then, but that element is the connection.

I

H

I

H

Maybe it's because just I'm structuring in terms of uh read message, one read message too, and I really need to understand what to invoke and which path I should take based on what message it is. So it seemed to me, like the first thing, to understand really.

F

I think it's a, I think. Any implementation experience here is is great, just trying to figure out if it's um implementation, guidance or if you are doing something specific, optimization or if we should yeah.

H

We should discuss this.

F

Just implementation.

H

F

I think more implementation guidance on the connection identifiers might be good anyway. Yeah.

F

G

Good, we have that in the issue now, so we will yeah. We just uh remember this and then on the error messages.

G

I think the maybe someone has a opinion here so so what we are doing now is that we are saying that the error messages should work like in, like in co-op, in the sense that you get some, you get some code and some text string, which is guiding the software engineer to when you debug, that's the type of error message, and it's not clear that this should be what the error messages should be at this point, that's not stated at all or or if there should be more than just error.

G

It's also security issue, depending on what kind of information you reveal here so, but any opinions on that what is needed? uh The opinion, the ques. It's basically a question in this issue, whether we need to have whether we will specify or will not specify these error codes.

E

um So it needs to be open-ended, um but there is value in defining some things that we know are clear.

E

I think that ikv one, for instance, many implementations, suffered from the fact that you really couldn't have any couldn't get any clue what was going on.

E

Even when you read the logs on the server, you often had no idea until you turned debug on um and in many cases people were unable to make things like ordinary people were unable to make things work um without getting an expert involved because simple things like you used, the wrong key were never revealed um and- and I think that contributed to uh the failure of of ipsec to be ubiquitous.

G

So can can someone provide uh someone who has been working with the implementation, provide some input on what in which situations, this uh an error message would be good or what kind of error message we need? How should we get to that set.

G

We could have this as an as a we could go. I mean not only all implementers are on this call. We could reach out to them and ask if they have some input here, karsten's in the queue now.

J

Yeah, I just wanted to to point out that this is a general portugal design issue.

J

um Generally you when you design error messages, you need to be aware of whether the error message has an influence on the state machine or not, and if it has an influence on the state machine, then you need to standardize it, and if it doesn't you don't um so, I'm I'm trying to understand uh what what kind of distinction uh people are making here. um Certainly, there should be an admonition to provide good diagnostics, uh but that's different from standardizing error messages.

F

Right now, it's a general texturing that the application can set to anything. It won't and I don't think the drop says anything about it, but the intention is that it should at least be locked.

E

So maybe this is less of an issue given google translate, but one of the issues was um um uh in ike at least was dealing with um local translation of error messages um and that's where it would have been nice to have them defined.

E

um I I think that it's reasonable to say that in in this environment that we're not likely to get random users hooking things up, um so I think that's less important, but I could be wrong.

G

So, michael this, this translation- uh I don't know if I got you right, but I don't think there is any need for for for um deviating from english here in this setting. What's that, no, the point.

E

Is that the point is that if you have an error number, then that number can be looked up in a table and um can be tran can provide. You know local information in a local language, about what you did wrong, uh whereas the english text string is, of course something that the other implementer made up and therefore isn't.

E

uh It could mean anything right so um that that's that's the that's the the thing I'm trying to say: okay, there's an smtp right, I mean we did we we we, we wound up with the situation where we got nationalized uh bounce messages which people realized they couldn't read. They didn't know what was wrong, and so we had to really be careful. We had came back and added these dotted error messages that had uh more meaning so that you actually could actually know.

E

Yes, I typed the I typed their address wrong as opposed to their mailbox was full.

G

F

Yeah, it seems to be things we should do here. Yeah. I think the minimum definite guidance, how the error messages should be used better and probably some standardization, then.

G

F

Okay, any more comments on this slide.

C

So just uh I put this in jabra just as a time check where nearly 25 percent of the meeting passed and yeah.

F

C

The first slide only gone yeah. Let's move on. Let's move on.

F

Then here also updates, based on the what we discussed last time. We have.

F

We have done the transformation from hkdf to more general extract than expand and for short, two hkdf is used for shake kmac is used and got several questions on this, and the intention is not to standardize any new cypher suits but like any all cosy. Algorith can be used with a private cyber suit, and this change does not affect any current implementation.

F

Then the other second future. Looking issue that we discussed last time was to look at implementing ad hoc in terms of a chem. I tried to do this for both the signature and the static diva helmand, the signature mode maps quite well to on that unauthenticated hpke interfaces.

F

The only difference is that hpke force extract and expand in one step inside the hpk functions, while adhoc used them as two different functions and use the intermediate keys for uh four things and derive several expand, use expand several times on the same intermediate key, then the static, the helmet does not map well to hp key at all, unfortunately, or it it it could be made to map.

F

But hpke do generate key pair inside its encap function, while ad hoc relies on doing generate, keep here outside of end cap, and this is an essential optimization in in ad hoc.

F

So at least my conclusion is that we should not do this change. It changes key derivation, quite much, which could have been worth doing, but the problem is that it also increases message size quite a lot for the static tv helmet.

F

So I don't think this should be done. I think it might be worth considering to uh to look at how in the future so that it's possible to expand it to to use pqc algorithms, but don't think it's essential it looking at the pqc outwards. I think there might not be a strong use case to use chem malgrids at all. It might be more lightweight or equally lightweight, with the pqc signatures, depending on the requirement and limitation of the pqc algoriths.

D

Yes, mr renee, um wouldn't it be better to uh rule pqc uh the races out of scope for now, and then uh you can always uh add another other suite id to accommodate that in the future right, because otherwise you have to uh already anticipate design, picks right.

F

Yes, I think the only is what I was considering here is that maybe with pkc, you need to send an array of of byte strings instead, instead of a single byte string. So I don't know if it even would be any changes to the protocol messages, but it would be good to make sure that if somebody wants to use a pqc algorithm in the in the future, they can define such a scifi suite.

F

For example, I think you might need to send the chem ciphertext in message three with the pqc cams, which you don't need now so, but I I think need to come back to if that requires any, but doing anything except except very small things to prepare for the future. Everything is out of scope, yeah.

D

All right, yeah.

F

Good next slide.

F

So here is a issue that was not discussed last time but has been implemented in zero. Three. At the last meeting, we had received a request to register cypher suits with high security following aligning with cnsa, and after that we have received a second independent request to do exactly the same thing.

F

There's also a request to make a more general non-constrained, but not high security, cipher suit. So zero three adds two new cypher suits one aligning with cnsa it's the as256, and then it has an a second cypher suit with asgcm and curve245519 is aligns nicely with what is used very commonly on the web. Maybe it's not um absolutely most common, because rsa is probably more common than ecdsa, but this would probably be the second most common used. Algorithm combination on the web today.

D

um One question here like uh actually two, but uh so the the first dash item on the switch uh the csnh cnsa suite. Would it make sense to also uh kind of uh to codify some of what pack is on the byte count.

F

I don't know, maybe then I guess that should be done for all the substitutes, yeah.

D

And then I'm asking is because in the past I got it. I understood that uh the 51 bytes was a very hard limit for some applications, but uh yeah. Some of these definitely don't uh accommodate that right.

F

No, if you want to reach that 50 or it's even a little bit lower than 51 after headers, is 45 or 46, then you need need to use eight byte tags and 32-bit uh public keys.

F

All right, 64 bytes signatures, yeah yeah, okay, so so these episodes are not fitting for for these use cases, but not all the cypher suits need to it. The requirement is that we have one cypher suit that fits these use cases.

D

Okay and and yeah, the other question I have is you: you mentioned several independent requests. Is there any uh source for that like would it be? Would it help that some people articulate that on the mailing list to understand what the background of those requests is.

F

I think one of the requests are on github in the issue. The other requests we received offline from a very large u.s company, but I don't know if they want.

F

But one of the requests and discussion is on on the this issue on github.

D

Because if the let's say, if you go for uh for cnsa suites, some of the optimization techniques that, uh in my kind of layman, version of looking at the lake effort uh have less impact right because uh yes, like some of the optimizations, that they have a diminishing return. If the buy initial byte type is already higher right.

F

F

I I think the person on on github is probably might be happy to answer what they wanted. Cnsa compliance for the person from the big u.s company that made us didn't did said that he could not tell what the use case was.

F

So I don't know, but we thought adding if people have used for this, adding cypher suits is quite easy. We have 48 of them with a one byte and basically unlimited with more bytes.

G

And this this algorithm doesn't have to have one I mean that could could easily take two bytes. I suppose this.

D

G

So we have plenty of cypher suites.

F

Yeah, did you want? Was it this? Did you? Was it a question about message eyes or did you want more messages? Calculations in the draft training.

D

um I I don't think it's uh it's. It's really required, but I I do remember that there was this protocol comparison draft in the elvik group, where there was a comparison between different idf efforts and what is the impact on message sizes right?

D

If, if some of these calculations don't make sense for this, I don't think it makes it. It is required to go through a very lengthy effort to codify it, but maybe add a line that some that some calculators only apply for sweet zero, for example, right.

F

I think that's all really clear in the elvik document it defines exactly what algorithms it's used, but okay.

F

Okay, any other questions on this. Otherwise, let's move on.

F

Slide then, I think we have two issues that I think we need to shortly return to, and then the rest is exactly the remaining issues from it: f109 no changes to these slides so next slide.

F

This is the issue as presented at idf 109.

F

so, and next slide is update on this. So this wrecking the oscar a80. This has been discussed. This was presented and discussed at the core working group, and this discussion has continued off the rate of 109 and there's already some preliminary conclusions.

F

One is that a new core draft to specify oscar count a the counters is needed. This is to fulfill the aaid limits, whatever they will be, then. Another conclusion is that something like oscar appendix b2, which is that you send authenticated nonsense to each other before your re-key is needed.

F

There might be an update and there might be an up optimized update of this, and then the discussion has been that it would be good with lightweight forward secrecy, uh for example, I hashane at some level, and one comment was that it would be good if this is done in ad hoc. You have since received some other comments. That might maybe it's good to do it in or score. I think both are good are possible.

F

The only difference would be where you want it. Do you want it in oscar without their dock, or do you wanted it ad hoc without score? We have in zero 3. We implemented a hash chain of the key prk4x3m, which is the last key in the adhoc key hierarchy, which is used to derive the application keys.

F

So the this hash chain is made by running the exporter, updating the key itself with the exporter and adding unknowns to guarantee that you don't get any short cycles.

F

I think it's still for far to start whether it is known this counter around a number or a counter plus random number, but in high level the cryptographic principles of this. Now, when I look I happen to, they agree quite very well with what kartik suggested already a year ago. I think, and I think the whole idea with a lightweight forward secrecy is based on that, but yeah any comments on this.

F

Otherwise this will continue in core old subway.

B

So and john this is militia. I just have a clarification question the nonce. You say that the nonce comes. It can be a counter random number or counter plus random number. So I'm wondering how do you synchronize this? Between I mean? Do you explain the messages? I'm not clear on the mechanism exactly how it works.

F

So appendix b2 in appendix b, to an au score, you exchange some nonsense with each other in the kid context, and then you derive new keys and that you use yeah.

F

So basically that idea here would be that you you do that, and then both parties reach out to oscor and get a new key with forward secrecy and uh the random numbers and all the message whole oscar messages sent by the by the initiator and the client that could be the nonce to the ad hoc exporter or or it could be a you could do it with a counter in ad hoc and then score.

F

You have to ask for a key or you could have the counter in auth score and oscar, ask ask with this sequence number or you can could combine these in in any way. The suggestion for from keratic was to use both the sequence number and the the message exchange messages with the nonsense.

B

Okay, but I'm confused about the whole mixing of ad hoc and oscar part, because appendix v2 to my knowledge is oscar. So this is the exchange of nonsense that happened, and now you are saying essentially that these nonsense get used in the ad hoc exporter interface to generate a new key for us. Is this correct.

F

Yes, so what oscar would? What oscar normally do is that it it calls the ad hoc exporter interface. Give me a key in this case, although oscar would call ad hoc exporter, and then it would call at some point later. It would call this ad hoc exporter forward secrecy function with the nonce to update the key in ad hoc, and then it would call the ad hoc exporter again to get a new key, that that is the second key in this prk forex 3m hashtag, okay,.

B

Okay, that is clear. This is clear, but we are essentially making. I mean we are making the assumption that is running above right.

F

For example, this could be any application protocol calling this. This function.

B

But you need the nonce.

B

Which might be.

F

A counter yeah, but yes, you need the reason that you want unknowns in this is because otherwise it might, if you have really bad luck in practice, is probably work anyway. But theoretically the hash of the key could be the same key again, and then you have a cycle of length, one which just repeat itself, so typically in cryptographic, primitives, you want to add something so that you can guarantee a long cycle.

B

Okay, and do we need any uh review of the cryptographic construction of this.

F

It doesn't hurt, but right now I think, let's, let's work more on the practical details, I think the cryptographic parts are not the hard part here. Maybe it's more synchronization problems and so on, but but absolutely all cryptographic review of this at a later at a little bit later, state or or right now, also and for the cs- is of course welcome.

B

Okay, so essentially we're proposing to move on to work out the details about the synchronization of uh counters and then to come back to the uh review of the crypto mechanism.

G

I think I think if someone wants to be involved in the discussion. That's that's very welcome right now, if you want to contribute or or part of be part of this uh fleshing out the details that that's definitely welcome. So it's no, no reason to wait. If you have an opinion here, I think, but it's not.

F

G

Not really finished all the details so.

F

Yeah, if it depends on the, I think, all help right now is welcome, but I don't think lake working group needs to ask for external review at this moment that can wait until this is a little bit more finalized.

E

So the high level answer is that we will re-key in ad hoc, not in os core. That's what I understood did I misunderstand that.

F

Yeah this is this suggestion is to make a hash chain in in ad hoc, yeah. Okay,.

E

F

Would be possible to make the same hashing in oscore and it has different benefits and disadvantages, so maybe both things will be standardized in in the end, yeah.

G

So this part is just allowing the onset it's just allowing oscorp to reach out for edward and get something it doesn't exclude. That oscar does something.

F

Itself, I think we can provide some when the oscar parcher a little bit more clear. We can provide some message flow, showing more details yeah right now. This is what this new function is. What is specified in airdoc03.

B

Okay, so what I hear is that we need to keep this issue open, keep working on it and then come back to the working group with more details. Yes, okay,.

F

Good any more comments, otherwise I think we move.

F

On so this idea encryption this. I also think we need to come back to so next slide.

F

We discussed this at last idf and the agreement in the group was that we should try to make something similar, like tls 1.3 sequence, number encryption, basically making a table from each cosi algorithm to an encryption algorithm without the integrity and use that I try to implement this, both in the specification and in the adobe test, vector codes, and my feeling is that this get complicated for the developer.

F

Tls use only the block cipher mode of these algoriths and already that is a bit cumbersome, but ad hoc encrypts, more data and would need to use asctr in stream, cipher mode and the cha-cha 20 stream cipher.

F

My feeling is that this make the specification a bit. It add complexity to the specification, but also add complexity, to develop this, which would be bad basically, a developer. Only having access to a code c library would have to dig into the implementation of the because the algorithms dig out, aes and cha-cha and then probably implement a stream cipher mode of these on their own.

F

So I think I would like to not do that and instead going back and doing either suggestion one or suggestion two um and suggestion one is how ad hoc zero two looked like. Basically, you generate key stream with hkdf expand option. Two would be to encrypt message tree.

F

Yes, encrypt message, two just like message three and then remove the tag if there is a well-defined tag which there is for all current and foreseeable future, because algorithms and this is implemented in ad hoc 003, but I don't have any preference really between these two options, but I think both of these are easy to specify and develop.

F

So I think we should choose one of these.

F

Any comments on that.

E

You preferred option two.

F

No, not really I yeah, but option two is implemented in their dog zero three option. One here is implemented in addox zero. Two we got some previous version wrote that we use the source cipher, which is associated with bad security, because people use it with a short key and so on, but I think so if we use that we should um fine-tune the text a little bit to not to get less negative comments.

F

So people don't react on this and think it's it's weak, but I don't really have a strong opinion about this and so far I have not received any comments on on github, but if people don't have any comments here, I think we just keep this issue open and wait for wait for more develop developers to comment on.

B

Github, so just a clarification question: what uh a e a d algorithms do not have a well-defined tag exactly so.

F

I think mac drew had some aero algorithm use some aes in some mode that make the whole thing look like a random string. It. Basically, it spread out the the integrity protection over the whole ciphertext.

F

um You can do that if you have some to pass encryption algorithm, but I think none of the common algorithms have all the commonly used. Algorithms have a well-defined tag. Yeah and if it doesn't, you don't need to. The tag here needs to be removed to fit in the 46 bytes in laura1 and so on. There is no problem if the tag is left. If you don't have this, if you don't need this very, very optimized messages, but the tag itself here does not provide any security, as explained in the sigma paper.

B

Yeah, so in summary, essentially, we would be good enough with option number two. If we were if we had only the cyphers with the well-defined tag, but you are saying in future someone might standardize ad hoc with one of these uh pipers that do not have a well-defined tag and no, I think, that's very unlikely. Yeah.

E

So so, but and if that did happen, the overall effect would that we would have bites that we didn't need to carry.

F

Yeah, like okay, 16, so yeah so.

E

If someone defines a cipher like that, then they're going to have to deal with the fact that it's a bit fatter and they may have some good reason for it and that's, I think, their problem at that point.

F

Okay seems common so far seems to lean towards removing the tag.

A

John just a question: I understand the discussion of the removal of the tag, but I don't see the connection to the block cipher and tls 1.3 in the text above.

F

So the connection to that was, if we go to the previous slide.

F

This was one of the option uh discussed uh at the last meeting. Option number three here um associate an encryption without integrity, algorithm with each aad algorithm.

F

And this was the suggested way forward at the last itef meeting, but after I tried to implement that, I don't think that's a good idea anymore.

A

Okay yeah. Well, then, it seems related to the second part of the next slide. Thank you, john.

F

Okay, then, I think, if there's no more comments directly, I think we invite more people developing ad hoc to come with input um if they would prefer to go back to solution one instead of two, but right now, number two is implemented in zero. Three.

B

But this is more of a cryptographic decision right so I mean I think it would be good to discuss this in the terms of the working of not only developers, uh so it might make sense to maybe send an email to the list opening this for for discussion, proposing option number two and seeing if there are any objections to it.

F

Yeah, I think, number two, it's quite easy to see that it does not have any it's. Basically it it achieves the same thing as a yes. What we suggest the last meeting, but just in another way.

F

I think one would maybe be more of a you could have cryptographic views whether hkdf expand is a good key stream generator or not. Probably, I would say it's probably better than as but.

F

That's more of a cryptographic question.

F

But sure we could I can. I think I already sent this to the list. So hopefully we can get some comments. There also.

B

Okay, so for the time being, I propose we move on with option number two yeah and keep it open in case. Anyone has any feedback.

D

uh John one one quick question: um if you can send me a crypto uh requirement formulation after the after this call, then I can look whether I can come up with something uh if possible,.

F

I decrypt the required what.

D

Adjustment specification like oh, these are the cryptographic constraints and then maybe I can see whether something else uh would also be a feasible option from a crypto perspective.

F

Oh sure, yep great.

F

F

So now we have new issues. um Should we take them in order or should we take this cypher suit uh issue first, but also renee have slides on.

B

So we have one hour and five minutes to go, so I think that is enough time that we go through the remaining uh seven of your slides and they run that wide okay. So I propose that we just keep going in order. Yeah.

F

Let me do that and then, let's make sure that we we we jump forward in time. So this is issue number 10 and 18.. It has to do with delivery receipt for message. Three key confirmation.

F

um This was firstly raised by call norman at all do at all doing formal verification of erdog, and they pointed out that the static dv hellman version does not have injective agreement because d to the power I y was is included in the session key material.

F

But looking more of that, I think it basically, the same things apply for also for the signature and also for tls. Basically, after sending the third message, the initiator does not know if the responder has or can calculate this session key, and it can go wrong in call norman at all, showed it in a very theoretical way, but you can also, for example, the responder might not like the certificate of the initiator and refuse the message.

F

The message can get lost. So, there's a lot of reasons for this and whether, unless you have gotten a delivery receipt and key confirmation, you might not want to store the key for long term use because you don't know if the other party has derived the key.

F

On the other hand, sending sending application data is not the problem that can the initiator can do that in parallel with message tree in all methods- and this has been discussed on on the the list there are.

F

There is an um draft in core draw of palombino core oscor ad hoc that allows the messages, the application, data and message three to be sent together this, and if you then require response, this solves some of the this problem in some of the scenarios, but not all, and the question is if uh so, basically to basically to you, don't need to get key in confirmation in ad hoc, as it's well known, any application data with a mac can basically be used for so as long as they initiate the get au score from the responder.

F

He has key confirmation, or- or you can imagine, co-op use cases where the data are only going in one direction. So one suggestion has been to add optional. Fourth message to ad hoc- and this should probably not be it- should be communicated somehow or requested by the initiator. If this should be sent.

F

And there's also so on github. We have received both possible comments that this is something that should be done and a little bit negative comments. That says that I don't see the indeed and this ads complexity.

E

It seems like maybe that in some cases it's completely not mandatory to implement, and um but in other cases you wouldn't know because who wants to re-key first, so everyone would have to implement it.

E

Maybe that's where the conflict.

E

G

So if this, if this is not mandatory to implement, then the initiator cannot request this, I mean that needs to be agreed beforehand that this is supported.

E

Well, so, if, if you have a case where you have a responder who's, always a server and therefore the point you know where was the point uh about the initiator is not the os core client. If that's always the case that the ad hoc initiator is always the os core client and therefore the ad hoc responder is always the os core server, then we never need it right.

G

It's only well well, you can still need it. If there are, I mean if there is like co-op with no response, for example,.

E

The co-op request with no response well, but usually you can get an act. At least you could say you could someone say well, I'm gonna have to put an ack in any way.

G

Yeah, the co-op okay, I mean, if you have an oscar act, then you're done. Then you have key confirmation that that's the response, but unless you have a response, then you don't have.

E

Yeah, so there are some cases you're saying where the initia, the ad hoc initiator, is the co-os corp client, but that the the co-app message that would travel inside message three um would elicit no co-app level response.

G

Is that that what you're saying um that was one scenario I don't know, if that's the scope of I mean, I think we should, but in the case of uh this draft uh mentioned here in the third dash, I think which it should be required to send the response.

G

E

Will solve that problem, but it solves the problem without adding any complexity to ad hoc, just make sure there's always a response right. So if we're in agreement with that, then it's only the case when that point is not true when the ad hoc initiator is not the os core client that we need to worry about about the question of whether we need to make this mandatory to implement.

G

But but ad hoc may be used without oscor and we don't really know what the settings are for for mandating responses in.

E

Those settings well, then, then, what I'm suggesting is that in that case, which we really don't know anything about right now, when someone comes along and uses that case, then they're going to have to say that message four is mandatory to implement.

E

That's all otherwise, it's optional to implement for everyone. Everyone else is like well, you may not get it. You do don't count on it. Unless someone else said it was mandatory implement. So I'm saying we shouldn't make it mandatory, implement. Let let the application owner say that.

F

Yeah, I think, make it: if we do this, I think it should be optional to implement absolutely.

F

But do you think that such an optional message for optional to implement message four should be added, then michael? Is that your yeah view.

E

I think a definition of message four should be added. I think that a a bit saying please send me message four should be allocated and I guess that winds up in message three or message, one, I'm not sure, um and uh but that that this mechanism should not be.

G

G

Good other other comments.

B

So maybe just a silly question on my side, because when I was going through the github issue, uh I saw one proposed resolution, which is, I quote, the recommendation is to wait with starting the king material long term until key confirmation has been shared.

B

So now we are talking about having message 4 in order to achieve assure the key confirmation, but I'm wondering if we can bypass this with a simple timeout mechanism.

B

Where uh we expect the application, uh the application traffic and the mac to be received, and once that is uh once the application traffic is received with the corresponding max, we consider the key as confirmed and we started long-term.

B

Am I missing something.

F

Or I think the question is, if we can or should require, always require application layer messages right after ad hoc or if we want to rely on ad hoc to provide the key confirmation in some cases.

B

Yes, okay, I see, but I mean we are not relying implicitly on what I said: we're not relying on oscar. We are relying on any application layer mechanism.

F

Yes, any any application, they secure application layer messages, basically with a mac, would do.

G

So malicious, what was your point that we should not specify message for or or that that we could? What was the relationship.

B

Well, um unless absolutely necessary, I don't think uh we should, but this is just my personal opinion. I mean, uh as I told you when I was going through the github issue, I mean, I think it was a comment by you you're on that.

B

Essentially we can just uh bypass this by having uh by waiting uh with storing the king material until the key confirmation has been assured- and that's to me means like a timeout mechanism that that is triggered at one side before the key is confirmed and the key is considered confirmed once application traffic is received.

B

Does that make sense.

G

But isn't this two independent things? Because you could set a timer and then you could still use message four to achieve the confirmation, so whether we define.

E

I

G

Or have an uh sort of a mandatory text about not using the keys until confirmation seems independent to me.

B

But okay, my point was essentially that I mean, if you have the key confirmed by the application traffic, you don't need message four and that the application traffic implicitly confirms the key.

B

So maybe I'm missing something: okay,.

G

Well, no, I mean the problem is that we don't really know about the applications and- and we don't know whether applications is able to confirm within within the time frame. So maybe that's that message four would be the right way to get key confirmation at this point and then at some later unknown time this is actually used, so maybe the application doesn't really know cannot really say for a long time. You need to wait before before the application is actually using the keys, but you want.

F

To have the keys.

G

Ready when you, after you've done the handshake.

F

I think one use case lifted by cal norman and the people doing, for my verification was that you use ad hoc without any application layer just for as a authentication to a door or something, and then you just store in in the log that you have done this and that would require key confirmation. Yeah.

B

Yeah, I follow that and I agree with that.

F

But of course you you could I think the question is: do we want to enforce that they use application layer protocol in addition to ad hoc in these cases, or do we.

F

E

F

Basically, you need to send this message for in some way, otherwise, either it's ad hoc message for with just the mac basically or it's some application layer protocol with a.

F

B

So yeah, I guess I if the cost of of adding message, four as optional as michael said, is not too high. uh I guess we can go and then make it stand alone. Make catholics stand alone and not rely on the application? Trafficker, because that's good.

E

But that would mean we would always send an extra message.

B

No, no! No! No, I said uh in case there is no implicit confirmation application. We have message four at our disposal to confirm the key.

E

Right but it doesn't have to be mandatory to implement.

F

No, I agree. Okay, so conclusions seem to be. We specify a very simple message for that. Basically only contains a mac. You signal that in message one or three with a bit in some way, it's optional to use and it's optional- to implement.

B

K

B

F

And any of the actions, otherwise, let's let's do that and move on to the next issue.

F

So here's the issue about t-e-e assumption this was also raised by the formula verification. They wanted more clearer assumption on where ad hoc and oscorp were implemented, and basically the trusted execution environment has gone from, basically only being as key storage like tpm to being a general execution environment like intel, stx and so on or in the arm trust zone.

F

So the question is what first, what should we give any guidance in the in the era draft on what should be implement if possible should be implemented in the te can also write.

F

If you implement this in a te you get these additional security benefits, and the third thing that we can do is if the assumptions regarding te is clear, then you could start to maybe change some part of the protocol, for example this hash chain that we talked about earlier.

F

Then then, you get better properties if that is in ad hoc, then or score, for example, if the assumption is that ad hoc is in a t, e and o score is outside of dte, um and I, based on the discussion in in on github, I think basically, it's possible to implement the whole ad hoc protocols, but maybe every assumption could be that the ad hoc keys are stored in in a tee. There are keys and any cryptographic operations on them.

F

um You have something to add your. um I think you were active in that discussion.

G

um Yeah, I think this. This is what what the reviewers um or the the the people who work on formal verification would want. Is the security considerations around this sort of what what benefits do we get from storing certain keys or secrets in the te? What what other properties we we we will get out of the protocol. So that's it's more like an understanding of how to use te in the context of ad hoc and writing that down in the security consideration.

F

Yeah, but I think it it came from the formal verific, but I think it's it's not so they they will not use ad hoc. I think what is interesting is how should we give guidance to people using ad hoc? Not people really doing, even if that's also good, to have clear assumption for people doing formal verification, but I think no, no all the time it's a bit broader than that.

G

I agree, but I think that's what the security considerations are for.

G

That's I mean for for explaining what parameters should be stored where so, it's not only for them it's for, and we could have this as an implementation guidance, if that's that's a better place, um but basically it should be clear what parameter what benefits is is obtained by storing certain secrets in in a trusted execution, environment.

G

E

I think yep go ahead, um so I I think that there's clearly a a pyramid of you know benefit right. um There's no point in putting the the ephemeral public keys in the tee and not the long-term public authentication key right. That's a that's, probably a silly thing to do um so. I I think that should be documented. um More specific advice really depends like the the ephemeral public key. If it lets you blow up the nuclear reactor, then maybe it should go in the t-e-e.

E

um On the other hand, if it all lets you do is turn on the lights, then maybe it's pretty irrelevant.

E

So I think that's going to be very specific and I don't think our document can really say that I think it should simply say make it clear what keys are related to what other are. Are they derived from or or related to something and the loss of certain keys? What does that result in and that's all and by loss I mean not compromise. I mean like um it like the key gets, destroyed or or can't be used anymore for some.

E

G

Do we need more guidance here, john? What to what to do.

F

I think I I think what michael's said is a good start. I think, unless we have any very clear I I don't think we will have any. I think the implementations will look very different and we we have to allow any type of implementation. I think we can only give guidance as michael says, explain what happens in in different cases. If you.

F

Mica talk about destroy keys, but one thing is: if key: if x is compromised, then storing then y is not compromised. If it's stored in a t, e e, um I didn't where, where would the key speed destroyed?

F

Would that be outside or inside the tee mic like.

E

If, like like, imagine if I do a firmware update and it decides to uh reinitialize the keys right so that that that may be, it may be perfectly acceptable for the uh ephemeral public key to be regenerated at a firmware update, but that the the long-term public authentication key is in the tee and therefore is never affected.

E

But another device gets their their coding wrong and some update actually destroys their their long-term key, because that was in oops. They didn't realize they shouldn't do that right.

F

Yes, destroying the keys is not the security problem. It's more.

E

It sure is if it leads to somebody deciding that uh they can't deploy this or that they want to use something uh uh weaker right: okay, okay, yes,.

C

So can I jump in with a time check, uh I think we're waiting for about 40 minutes left. I'm not sure this issue is really on the critical path. No.

F

Let's move on, uh then we have forward and backward secrecy. These are, um I think we have this. We have already discussed this in the aad key thing, uh but basically re-running one option to get forward and backward secrecy or post-compromise secrecy is to re-run ad hoc with the new dfe helmand. Then you get both of these properties.

F

As pointed out by kartik and now we're starting to implement. You can get forward secrecy, but not backward post compromise secrecy by only using symmetric, crypto and basically a hash chain where you threw away all the old keys. I think we can take next slide.

F

And one thing that you can do one basically doing redoing ad hoc, that requires four asymmetric operations by the initiator and the responder doing this lightweight forward secrecy. That requires zero, asymmetrical operations by the parties.

F

What you can do in between and what the signal protocol does, what it called a double ratchet.

F

Is that it it periodically for signal every message, but you could do it every nth message or something you could send generate a new ephemeral if a helmet key and send to the other person who just calculates a new key but doesn't really send any back. So you have ephemeral static if a helman ping back and forth, and this requires two asymmetric operations on the initiator and one on the responder, and this would then be a little bit but not much cheaper than rerunning ad hoc.

F

It requires one message, and maybe two: if you want to have a ack and basically half the amount of asymmetric operations. uh Comments on github so far. Is that, uh let's not do it, the trade-offs are or not worth it. That's too much much complexity, and if you want good security, you rerun ad hoc instead.

F

So I think that is the current conclusion that you rerun ad hoc or you do this lightweight forward secrecy, but we we thought we should raise these and have a discussion if there's anybody feeling otherwise.

F

Doesn't seem to a bit complicated, I can not really explain either exactly what security properties you would get from this, and it might also lead to a lot of synchronization problems that are might be easy or hard to fix. So um I think, if there's no comments, we go to the next slide and have the conclusion that we don't do any form of ratcheting.

B

Yeah, I agree with that. So let's go to the next slide.

F

So- and here is uh these are several slides and this is a complicated issue, a lot of discussion and I don't think, there's any easy answer to a lot of these questions. So this is related to the cypher suit, with different shaw, algoriths.

F

And the use of sha 512 in constrained iot, which is not implemented everywhere and then also discussion, of which cypher suit should be mandatory to implement if any selfish suit should be mandatory to implement and there's a lot of comments on this. This has been discussed for a long time and there's comments in a lot of different direction.

F

So the first is device support here. Ecdsa and sha, 256 and p256 is the current default choice. It has very wide support.

F

Show 512 is not supported at least not in hardware, on a lot of devices and will probably never be uh shaft. 256 is often hardware accelerated.

F

And yeah, we also heard people saying that we have implemented java 512 in software and it's it's very little code. It's not a problem, but the conclusion might vary what how constrained devices you have?

F

Maybe I think we go through all the slides. Unless there's any comments, then performance, several people have pointed out that they want they have. They are depending on low latency and with modern devices. It starts to be less and less of a problem but curve they say: curve25519 is significantly faster.

F

The numbers I've seen if you have optimized implementation of both is that curve. 2519 is 65. 70 percent of p256.

F

Is a number I got from a company recently? If you search on the internet, you can find very different differences, but it's hard to compare. Often they compare unoptimized code for p256, so I think the difference have shrunk. The last five years. You could see larger differences five years ago than you see now then third trade-off here is security.

F

We have received several people saying that they prefer the security in ed25519 compared to ecdsa the then rendez saying that he absolutely he despised the security in ed-2519.

F

And the I don't know exactly why renee's set up, but one thing is that deterministic signature, algorithms are not very good for accessible iot devices because of side channel attacks. um John, can I have a comment for a second absolutely do that? I don't think I despise it like that. Okay, yeah, you you, you use quite hard words. Sometimes yeah.

D

Yes, that's a personality flaw of mine right, but please explain.

F

D

So I I think uh both ec dsa and uh at 255 at the dsa are uh theoretically they're fine monsters, norske, even the other one was easy, dsa, the only problem. The main problem I think with ed25519, is now that it's deterministic and it's basically there are lots of papers. There's a recent one in the ssr uh standardization crypto conference about taming the many versions of at 255.9, and I think that's the main problem.

D

Basically, the the specification has to be fixed so made to make it usable in all ifd settings that requires getting rid of determinism. Yeah.

F

Good so next slide.

F

Yeah before that, I yesterday we talked to a swedish firm and they said they preferred e-d-d-s-a because of ed-25519 because of features that they can implement threshold cryptography.

F

There is a risk, quite new cfrg draft on threshold cryptography with um with curb 2519, and they said that they can do with curve25519, but not with p256, at least not in an easy way.

F

Then so question here is: what should we have as the mti cipher suit? If anything, it does not seem to be an ideal people. Support is important. So if you have a single, it seems that ecdsa p256 might be the option, uh but other people has there's a lot of people. Also wanting the security and performance of ed2519 different group of people wanting different things, and but the question is: do we do we have to have a mandatory to implement algorithm cosi? Has the text that applications using codes needs to define the set of security?

F

Algorithms that are to be used? Ad hoc is not an application. It's it would be used by applications, so maybe we could have the same text or we could have both of these algorithms mandatory to implement. um So I think this is the technical question, but it's also a political idf question. I know I don't think the ad is here and I think if we, if we don't want to have a mandatory to implement, then I think we need to confirm with the 80 that that would be acceptable.

F

B

Okay, so other than these two options, I believe renee had his slides uh presenting a third option, so I propose that uh rena goes ahead with his slide and then we come back to this and make uh and discuss this in more details. Yes, does anyone object that.

F

I don't know, I think, that's great, I don't know if renee suggested, that should be the mandatory option to implement or if he he's definitely suggesting that that should be a cypher suit that can be used. Yeah yeah.

D

For a political discussion or a non-technical discussion, I don't want to focus on the technical merits right, yeah, sorry,.

G

Malisha there was a last slide there in the presentation. Should we take that first or.

F

Yeah, okay, yeah this one yep, okay, so yeah! This is quite uh related to rania, so, but basically in. In addition to do these two, you can think of quite many future algorithms. It's unclear what will be used in iot in the future.

F

uh Renee has suggested a wire strass version of ker 255 with shaw 2056 that solves some of the problems with, but not all problems with the other two uh hillary started talking about that. Atf should maybe look at standardizing something even more optimized called qdsa and there's also a question whether shaw 256 will be the.

G

F

Of the future, I've seen a lot less discussions in other groups in idf about using shade or one of them, something that comes out of the least lightweight cryptographic. Standardization, for example, gimli.

F

And then there's the question about random deterministic, random or deterministic plus random renia lifted earlier. I think then we can go to arena slide.

D

Hello, um I just wanted to uh ask for some time and and I'm grateful that I was given the opportunity to uh discuss uh a potential uh option for a cypher suite in the the adult protocol. So let's go to the next slide. I don't think I can do that myself right.

D

Oh yeah yeah, so um this slide looks very busy, but uh essentially, if you look at the first column that uses that is listed as ecdsa256 and ecdh256, that is cypher suite. That's currently supported in ad hoc as option two or three with some symmetric component as well, and it uses uh the well-known list p256 curve, uh sha-256 and ecdsa or vector diffie-hellman with kdf based on xia256, um the second column um it. uh It is uh addox suite zero one.

D

It uses uh the at two five five, one nine sixty scheme and it uses x25519 as the diffie-hellman key agreement protocol. And if you look at those two columns, you will see that there are some sticking points. So one of them is uh it's not clearly visible. Is that uh in? If you use the second column, then you have to use shout 512, because it's used as the fixed building block in that signature scheme.

D

The other feature is that it's a deterministic signature scheme and if you look at the diffie-hellman component, you will see validations that it checks as a as a row item just before the end, it's more lenient in the x25519 protocol, because basically there, every incoming public key is accepted, whether it's on the curve or the so-called twist of the curve.

D

What I would like to suggest considering is maybe there's room for another suite. That looks a little bit more like the nist, well-known ecdsa and co-factor davie hellman in terms of formatting and in terms of the curve equations, because I think that would actually lower the implementation cost, especially for implementation that uh either want to implement both or maybe they already have uh the x2559 under the hood um or they have already existing hardware. So, let's go to the next slide.

D

So the next slide is just basically uh rephrasing uh the scythe suites that are currently suggested in ad.

I

D

And I suggest basically adding as another suite and I only focus on the public key components where essentially, instead of using the nist curve, we use uh an equivalent of curve25519, but it's whipped into a format that is fits right into the nit specifications and it's called uh in in the speak of the elvic draft. I have on this y25519 where y stands for ifstras and the main features of that is are that uh devices that are currently out there.

D

They may have a generic implementation uh that features uh the uh that allows implementing this curves and all kind of other curves like a brain tool, for example, so they can just run it on an existing hardware.

D

Implementation example is nxp, has done that so there's something on that in a document oops, I think, there's an oops, um and the other feature is that if we actually would use that way, so essentially reuse nist compliance as wanted criteria, it may be possible to get fips 142 accreditation for essentially on the root curve 25519, except that we just represented in the virus transform.

D

So one other thing I want to mention on this slide is the the last kind of brown colored thing it's. um If people already implemented curve 255 online using the so-called montgomery letter, they can just reuse 99.9 percent of that code, just to add a little wrapper to implement what I suggest, and I think it goes too far to go into the details, but I have some further reading on the next slide.

D

So one thing is some idf draft material that's listed on the bottom, so I have a draft uh specifying how all these so-called curve models that have been floating around the last five years in idf, how they are all related like viastras, montgomery and twisted attributes curves and it's currently.

D

I think it should go to iesg soon, hopefully- and I have also some background information that explains it without having to read through the draft- and I presented that already like two and a half years ago. So that's the last item here then this uh bias trust version has been specified in some form in some nist draft implement specifications. So if they get issued then- and we see it's compatible, we can just basically make sure it's the same.

D

So then, uh if we use this viastras curve version of, I think everybody loves curve25519 for speed, but in a slightly stricter way, then we have something: that's compliant with nist specification.

D

We can use uh fips documentation and ultimately, I think the main benefit would be that we would be able to have a device that is able to stick to fips 142 requirements, uh and I've looked at that yesterday and I actually updated the elvik document a little bit because of that at all the requirements in the fibs 142 document and the latest version is, uh has all kinds of requirements on how random number generators would work and which checks should be all be carried out and from the way I read it.

D

um We can satisfy that if we uh would go for something like this, so that's that's all. I wanted to bring.

B

Forward: okay, thanks runner, so if I'm understanding correctly you're not proposing this for an mpi suite or rather there's a as an option in ad hoc.

D

It depends on the on the group you know like I, I I have no, I'm not building devices. I I just think this is a viable option where uh devices that either want to uh speak only uh curve25519 stuff. They can do it in this compliant way.

D

If we use this approach or if devices want to speak, both nist curve, p256 and curve255l9, they can do it in a lower cost manner and we don't have to implement xiao 256, because, most uh I I spoke with some people at synopsis, for example, and they they don't do one or they go they. They only implement things that are not uh tailored to one implementation. They just do.

D

One thing that is uh is more generic, but uh maybe others will right and obviously there's a there's, a huge development base of things that are curve2551 related, but it can be leveraged in by just using this little uh mapping from montgomery to vias rosenbach.

G

I have one uh question here: I mean john listed in his slides, the three things we are sort of discussing the device support the performance and the security is, I suppose, that's covered in in some of these publications.

D

um Yeah, so I I think the device support for the the nist curves is quite high because it uh you know, there's a lot of hardware support if you look at lots of processors that are also relevant for the iot space.

G

Sorry, you also need to transform to.

D

uh Yeah, the transformations step is essentially just a field edition, and it's it's it's depending on, of course, how the how the code is being implemented, but if it's software based it's just a one-line, call to a field edition and then an online call to a filter dish in the other way around to go back um so but yeah. So if, if you want, I can uh I there's lots of material in this elvic draft to to support those kind of claims right.

D

So I think there is support for for people who already have a 255 r9 implementation to uh also implement this stuff. It's a actually extremely small effort to just build a wrapper around it.

D

The performance, I think the main performance is the scalar multiplication in electric curve crypto, uh although in easy dsa the you have to also do a snowballed, inversion step, which makes it slightly more expensive, but not that much so then so. Obviously, it's the performance goes down a little bit, but it's only a few percent.

D

C

One sorry when I I just conscious of time we're at the 15 minutes remaining, um so I mean I guess we want to discuss the concept of mandatory to implement. Yes, yes, stephen and, and then you know whether a new cypher sweeper from an rfc yet is an appropriate choice. Is probably the second question not first.

F

I think, as as soon as the closer registration for this is, is done, you can use it in ad hoc with a private cipher. So, but I think this is probably a useful. This is probably useful in some scenarios. I I would personally be open to to make a cypher suit for for four. For this.

D

So I I just want to comment on the last, uh because there was a question that girl and about the security as well. I think uh there are at least to my knowledge. There are no uh security issues with ecdsa nor snore, if used properly.

D

The main difference is that the the ddsa spec this this this uh wire straps version of curve2559.

D

It does not do deterministic signing so the current spec. It satisfies all the security requirements, I'm aware of at least in also in ied spaces, where physical security is important. Okay, thanks.

F

So back to mandatory cypher suits, we choose one of these two we choose both or do we just numb.

B

So maybe maybe the first question is whether we do want to specify an mpi street uh in nether. uh Do this? Do people have strong opinion on whether we need to specify an mti or leave it open, as it was done in cosi,.

B

Do we have any opinions on that.

G

Well, I think, as we've seen there's a lot of. uh There are basically two camps here, so if we could avoid saying that you need you need to have just this curve or or this algorithm, that that would be the best solution.

F

Yeah, I think in general, most of these iot devices they cannot have both. They will choose one of these and order an s-curve and implement only that.

F

So I think I think doing like couples. It sounds like you have two very strong camps with different opinions here. So I think doing acoustic would be good, but we probably need to talk to ben to confirm that that would be an he thinks. That's an acceptable option. So we we don't get stuck in isd later.

D

Well, you you know, I can I got to get one comment um I have. I just have a question like is potentially in the long run, fips compliance.

D

F

Can you clarify reading.

D

Well, if, if phipps compliance is important, then I think any solution has to be compatible with the the fips on 40 dash documentation.

F

Right, yeah, okay, I I don't know too little. I guess the rfc will not be fips compliant. It's a specific implementation that gets fit pips, compliant or.

D

uh Which is which is true so so in case, uh for example, in case ed255l9 uh will be in the final version of the nist drafts, then it would be, uh for example, usable in u.s government implemented applications right um the currently.

D

So the thing that I've been looking at yesterday is whether the x25519 protocol would be able to get a fip stamp, and currently I don't know so- maybe if you want to have a look at that as well, because I think it's important that some of these devices that you're targeting that you don't block out a particular market and use government market is not huge. But it's uh usually it's perceived to be a good thing. If you are also compliant with uh niched things right.

C

So I think again sorry to interrupt but we're down to 10 minutes and uh fips. Compliance is probably a different issue than mti cyber suites related, but different. So maybe renee. If you could raise that as an issue and github and.

D

It probably requires it's important for the application domain that you do you're targeting yeah.

C

Yeah, but I'm in the interest of time, I don't believe we have time to to resolve that today, because it depends on people checking what they care about. But it's a good issue to raise, whereas we have the empty eyes in front of us.

F

Great, so any other mti comments, except the comment from alicia that doing like cousy would be a good try to do like jose would be good.

B

That was a question I mean, I thought the question. My personal opinion is that doing the cause is more of a generic rfc than standard uh the net hockey is and that we will be losing in terms of interrupt interoperability between the between the implementations. If we go that way again, that is my personal opinion, so I'm intending to vote for having an mpi street, but I understand that there are different opinions involved.

C

So just um I think, in terms of the process of um one thing, to notice it's kind of unpredictable as to whether you get given out whether you get problems from the isg or at ease with respect to this or not it's some. You know you're trying to predict the future and the personnel on the isg at the time is not always predictable.

C

um Second thing to just offer, as an input is in this case there might be an option to say something: like um you know, if a device is less constrained, then it should implement both these two cypher suites um and if it is constrained, then we'd encourage use of one of them, but we know that you know not. Everybody's gonna do that. So there might be some halfway house here. That makes sense.

C

And michael, you had a comment in jabber that that sounds like it might be worth uh getting onto the record.

E

Okay, so um my suggestion is that I think we should allocate a code point, that's fine, and particularly if uh we can do that without causing a down ref. um If not, then I believe that the elwig document should allocate the code point in our registry. That's fine by the way it works. Let's not decide on mandatory to implement in this document is not going to fly it is there are so many different considerations.

E

uh Ipsec uses um an rfc 820 8221 is the the latest one with a series of should plus and must and should minus so, for instance, p 256 suites are probably should minus, because they're hardware accelerated right now, but many people don't like them and this algorithm may be as a should, plus um and maybe ed 2519 is a must or not, but put that in a different document. That's going to change over.

F

Time, thanks very good comments from both.

G

Stephen did I get your comment right? The potential formulation is, if device con less constrained, then implement both if device constrained and implement one of these two or what? What was the.

C

Suggestion, rather than advice that I'd recommend strongly but yeah yeah. That's.

G

A really good idea.

C

I I think it might be: there may be middle ground there. That makes sense for implementers, because I think a lot of people write. Generic libraries will implement everything and it's people on the constrained side. Who'll have to pick down to one or two things, and I think we could give them good should level guidance that would work for lots of them, even though some will do weird things.

F

G

So, if less constrained then must implement both and or and if not we should it's always should I thought we should yeah. I thought you said mandatory to implement, then that's must right not always.

E

Should is, should you have a good reason not to implement it? uh Okay, sorry right should is you should do.

I

E

Okay, if you have a good reason, then there's a a reason uh like none of my none of my my vertical that I'm in cares about it right. Okay,.

I

E

It was deemed insecure by nist last year or whatever good thanks, thanks michael, but that's why we don't put it in this document, because we need to be able to to mark the document as historic as time moves on right.

F

Yeah, but that will require an another document now and that still might not fly with isd.

E

The precedent is ipsec and that's worked very well.

D

I can ask the question: how do you, how do you achieve interoperability if you don't have a common core of algorithms.

E

Well, almost nothing is interoperable unless we agree on the connectors.

E

E

So what happens in in in many places is that there are other entities like, for instance, uh uh zigbee, which will say, and the mandatory to implement algorithm is x.

E

If you want to be within our uh conformance list and it's way beyond the the cipher right, you have to get the frequencies right, you have to get all sorts of other stuff right or it won't interoperate forget about the crypto so specifying the crypto is relatively easy for them and they are going to do a compliance check on that, so they're going to make sure it works.

E

So it really is it's it's not that important for us to say which one's mandatory to implement whatever that it means, as opposed to us saying these are some algorithms that you should implement so again. So.

C

Again, time check we're down to four minutes um and we had francesca who I think we pushed last time and so and we probably won't sort out this issue in four minutes anyway. So maybe suggest we switch over to francesca's uh report sounds good and then we'll we'll talk, then at the very end about whether to have another interim.

I

Okay, thank you. Can you hear me? Okay,.

B

Yes, we hear you.

I

Good, thank you. So I just wanted to report quickly about our first edoc interrupt next slide, so we um organized something very shortly with two implementers. So there was timothy and stefan and a tweak. We had two hours interrupt to test those two implementation implementations against each other and uh we tested um only based on the exchange that is described right now in the in the draft in appendix b1.

I

So that was the signature authentication x, 509 certificates with the method 0 and the selected cipher suite was the number zero. So these are the algorithms that were used and the result is that it was successful in one direction and um so the exchange passed all verification and then the messages were created and uh verified, etc, but on the other direction it was not successful, but not because of adoc implementation, but because of connection problems.

I

So I didn't manage one implementation managed to talk to the other one, and I took detailed notes- and this is the google drive for it, which should be open and available for everybody.

I

So next slide, please so next steps uh already we the good feedback for for us authors about the test vectors um to be so the feedback to be incorporated, and uh we want to add more details to the test vectors and we created an issue, a github issue into into the um about that into the github repo, and it's both about the draft so adding some details to the draft and more test vector and also about the vectors.txt.

I

That is contains more test vectors than those that are in the draft and also, as you might have seen. I I started doodle about an interrupt after the holidays, possibly in the third week of january, and if you're interested to participate would be great, please go and let us know so. We can pick the best date for everybody and that's.

B

It okay, that was the last fight thanks, francesco.

I

B

So with that, I think we went through all the agenda items uh stephen. You wanted to discuss the interim before itf 110 right.

C

Well, yeah: do people want one? um Yes, please if people do want one I'm guessing late january early february is the only sensible choice to to yeah.

C

Do other people also want one a few plus ones in the chat and jabber or webex would probably be helpful. There.

C

So I see just a couple of people want one. So, yes.

G

Yes, I think it's good to have another one.

C

Okay, all right, so we will take it to the list. um We'll suggest some dates in, uh like I said late january or early february, because the next ietf meeting 110 is that early march this year. So it's a bit earlier.

C

That was all I had malicious.

K

Want to wrap it up. Oh yes,.

B

So that would be all uh thank you all for attending. I hope yeah, I'm recording when fine. uh So, let's uh enjoy the holidays, let's think on and think up on the mailing list and on github. Regarding the specific issues, uh we will launch the poll uh this time about the uh the dates for the next interim and yeah. I guess that's it. Even if you want to add up something.

C

No just enjoy the break everybody and it's that, let's hope for a more fun 2021.

K

Definitely, let's hope you meet in 2021 face-to-face. Yes, indeed,.

I

Thank you for today.

K

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

B

C

So militia I guess we can, by maya to figure out minutes and all that kind of.

B

Stuff yeah that.

C

Works good grand. I have to run off something else.