Internet Engineering Task Force 108, 31 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF108-LAKE-20200731-1100

Description

LAKE meeting session at IETF108
2020/07/31 1100

https://datatracker.ietf.org/meeting/108/proceedings/

A

So I guess we're scheduled to start we'll give a couple of minutes just for people to trickle in what.

A

A

A

A

All right, so, let's get going so uh welcome to the lake working group meeting of ietf108s, not in madrid. Sadly, but hi. I'm steven and.

B

Really sure you can introduce yourself, I guess, and I'm alicia I'm glad to have you here and.

A

Okay, so we have a relatively short agenda. I don't know how we'll go to time, but we have like an hour and a half, or so um you can see the various links you can see. This is the noteworld that, if you've been at other meetings during the ietf week, you have seen it you need to understand what it says and here's our agenda.

A

So we have we're in the middle of point zero uh agenda's gone um then, given that the working group have adopted ad hoc uh we'll have a introduction to that which is some of which was repeated previously, but some of which has changed over the last while so it's it's worth doing as a scene-setting thing, there's a few open issues, we'd like more and then there's some discussion of uh some proofs related to ad hoc and aob. So does anybody want to bash the agenda right now.

B

Oh, I see no one in the queue. Let me neither.

A

Okay, there should be time for aob at the end. I suspect uh it need be, um otherwise uh we can move on to quran. So if you want to jump in the queue around and send requests to be sending there, you go okay, so the so manager will drive the slides, if you just say next slide at the relevant point in time. That would be great.

C

Okay, thanks yeah. Can you hear me well.

B

Yes, we hear you will just say next slide when you want me to flip slide. Please, okay, thanks.

C

um Yes, so just a background here we have been adopted. This is the working group draft which we will adopt it in late june, so this version of the draft is essentially identical to the latest individual submission, uh just some references, updated and and some comments on the test vectors in the appendix.

C

So if you've read, if you read that the previous version, the latest individual submission there is, there is not so much new in this, but then again the protocol has been changing last year and we have never given any detailed description in lake. So so that's why we're having this this presentation next slide. Please.

C

So there there are a couple of slides for background.

C

uh It's really really small font here, let's see if we can get read everything and um through through the meat echo um so, but there are two background slides in case you haven't missed the discussion the last half year, um so the edoc is uh is intended to be like a lightweight authenticated key exchange to match the lake requirements and in particular there are some challenging performance benchmarks and there is also the ambition to reuse building blocks used by oscorp, which is lacking an ache, and those building blocks are primarily seaboard for encoding, cosy for seaborne, encoded, crypto, wrapping and co-op for default transport and just a disclaimer here.

C

This presentation does not contain anything on security claims, as there is a separate presentation on that following the next slide. Please.

C

And just note on applications, we believe this is generally applicable and useful to iot settings where you have constrained links, and so you need to communicate between a thing and cloud or thing to thing at least partly over over some some technology, which has restrictions on on message, sizes and amount of bytes.

C

So and specifically, we know that people are interested in deploying this for the join or bootstrapping scenario when you have a constrained device joining the network for the first time, and there is a large variation on on these scenarios, so it could be different network conditions with special radio technologies or multi-hop, or a number of devices connect at the same time, which makes these links very busy, then there are other features which are specific to specific deployments, like security applications happening simultaneously with the authentication like authorization or enrollment of a certificate, and then there's also a large variation in the type of credentials, you'd like to use device certificates or raw public keys, and sometimes you would like to reference those so there.

C

These type of variations is something we need to cater for in the problem. Next slide. Please so now this uh from from here on to to the end, this is focusing on on the protocol. um So let's go into the different message fields. There are three messages and an additional error message, and each each message is a sequence of seaborn coded data, so using the sibor sequences, which is, has now become an rfc and yeah next slide. Please.

C

So, on a high level, we see the this is a different help, diffie-hellman key exchange, so we see the efmeryl public keys, x, gy and we see the encrypted blobs here. The first is and message two: there is an xor which is different from from previous version of the protocol, which was an authenticated algorithm.

C

Now it's changed after carefully reading the sigma sigma analysis, and then we have an aad in the third message, so we'll come later to the encryption keys and the identifiers, but just for no now we note that there is this uh signature or mac structure, which is either a mac, then sign or a mac, and that depends on the authentication method.

C

So that brings us to the next slide.

C

So adhoc specifies four authentication methods targeting the variety of it use cases mentioned before so, for example, the initiated responder could both have signature public keys to authenticate with, or they could have static, helmet keys or it could be a mix and um yeah I mean these. The setting here is, uh I mean this is what we think is is needed by the scenarios. This is something we could could re-evaluate, but but, as it seems, we we still need to have because of the ecosystem around pki for authentication and the tools available.

C

We we do need to have signature, be able to have signatures. That's also.

C

So the the reason why we're using looking at things like idev id and this ieee 802.1 r 1ar is, is requiring signatures and there's also the device certificate enrollment setting where you want to combine that with ad hoc, which which requires the use of signature for authentication.

C

But on the other hand, if you're using uh raw public keys, then you you, don't necessarily need to use signature public keys, but you could get much lower overhead with republic with the static divi helmet and there is a mix of raw public keys and certificates which leads to this mix up of credentials.

C

So next it's like this, so these four methods are then the choice of method is then signaled with the first element in the first message, so the initiator selects and the responder can then either accept or reject and and stop the protocol.

C

In this first element we also have a field on correlation, which is the an encoding of what what correlation is provided by the underlying transport and that's useful, uh for example, for for the connection identifiers, and so there are explicit connection identifiers for the initiator and responder, and those may be omitted if, if the underlying transport already provides that information, so, for example, with core equals one, there is a correlation.

C

It's indicating there's a correlation between message, one and message two, for example, in the case that initiator is a co-op client on the responders, a co-op server. Then the co-op protocol provides the token, which already has this information about correlation.

C

So the connection identifier in the second message can be the ci in the second message can be, can be omitted next slide. Please.

C

So this brings us to the cypher suites, and the cypher suites is an a cipher. Suite is an ordered set of cosi code points, both um cosy algorithms for ad hoc and also for the application in this case auscore.

C

So it's a seven tuple. uh The five first are are the algorithms for ad hoc and the two last are for for the application, and this seven tuple is then identified by an integer, and here are the four cipher suites which are defined in the draft next slide. Please.

C

So each each suite is an integer and the protocol field suites. I is an ordered set of suites, starting with a selected suite and following the supported suites, which are the cipher suite which the initiator supports in order of preference and this uh supported suites that can be truncated at the end and if the truncation of the supported suites is only only leaves one suite coinciding with the selected suite, then you can just use that suite as the element of swede's eye next slide. Please.

C

So here here is an example of how cipher suite negotiation works and it's using the error message. So the error message in general has potentially three fields: it's an optional connection, identifier, it's an error message, which is the text string and it's optionally, the suites r containing the cipher suites in suites, I supported by the responder, and if it's only one, then you could have just that int.

C

So here's an example of using the the error message: suites r can only appear in responses to message one- and this is the case here. We have message one containing um it's an initiator supporting cypher, suites, five, six and seven uh select suite number five. Responder, however, does not support suite number five, but suite number six, so it responds with r equals six, and then a new session is shown here where the initiator is selecting suite number six and includes uh a truncated list of supported, cypher suites next slide. Please.

C

And so now we come to the credentials and identifiers and, as we've seen, we need to support a variety of credentials and the id cred for initiate and responder are used to enable the retrieval of the credential.

C

The id cred is encoded as a cosy header map, which means it's a seabor map and it's using specific cozy header parameters from from a certain iana register and out of this register, you could see you could, for example, you could use. Rpk can be identified with a kid header uh and certificates, which kid is essentially a key identifier, and a certificate x.

C

509 certificate can be identified using the x5t header, which is a hashtag certificate or xyu, which is uri now the actual credentials credi and credit are they are covered by by the signature mac here. So that's what what's being integral protected next slide.

C

Yes, so that brings us to so. These identifiers are encrypted as well as signature mac, and that brings us to the to the key hierarchy, and this is really small font now, but fortunately there are colors here. um This this picture is inspired from the from the tamarind formal verification paper.

C

um There's a question in the in the chat here: what does rpk mean? That means raw public key, but apparently he left the room. Maybe he got the message before leaving, and so so this key, as I said this, this picture was taken from from a simpler version was taken from the formal verification paper. Thank you very much for that and I tried to fill in the details. So let's use the colors.

C

So in red we see the different helmets shared secrets at the top. Is the ephemeral fml shared secret and on the left, it's the um ephemeral, static, shared secrets, and this is their input and the output here on the right hand, side in blue are the encryption and mac keys.

C

So a little bit more careful. Look. We see that at the top is the ephemeral, ephemeral key, uh which is uh which is and to the left. We have the female static keys, which are used together with hdadf extract green box to get the pseudo-random keys, which are the orange boxes and and there's a dependency on method here.

C

I'll get back to that method is indicated with the letter m and the pseudorandom keys are in turn used together with the transcript hashes from the message in the hkdf expand to produce the encryption, mac keys and also the exporter api, and some of these macs are signed, as we mentioned previously.

C

So just for example, we take method 0, which is the zig zig both have signatures, and in that case there are no ephemeral, static keys, so the input from the left is omitted and the um the pseudo-random keys are all the same, and then it's only differing in the transcript hashes.

C

In this case, the max are being signed, or, as another example, we take the method three, which is the static diffie-hellman static, diffie-hellman case when um both the fml uh static, shared secrets are involved and their the prks are all different, and in this case they're the max are not signed next slide. Please.

C

And the final point on the in in final field in the protocol is the auxiliary data, so ad1 2 and three, and these are intended as integration points for ad hoc in in lightweight security applications, so, for example, using this in third-party authorization or or unrolling a device certificate together with with the authentication.

C

So there is, this is an optimization.

C

So this particular example here is showing the third party authorization optimization, so instead of first running an authentication protocol, uh this is a device now joining a network, a device on the on the left hand, side a domain authenticator in the middle and they are running ad hoc and then there's a third-party authorization server on the right.

C

So, instead of first running the authentication protocol and then later on, run a protocol where you find out whether you actually are authorized to connect to this this network or not.

C

This procedure is doing the authorization embedded into the authentication protocol, so the auxiliary data is used for authorization information and provides information such that after the authentication protocol there is neutral, authentication and also mutual authorization.

C

So more details are provided in this draft. Here: okay next slide.

C

Yes, so we're done with going through the protocol fields. uh There are two slides more in this part. uh One is about this. One is about how to transport ad hoc in co-op and another use of oscore.

C

Ad hoc may be a very straightforward map to co-op just using posts and and the response code like 204 and then the initiator may either be a co-op client like in the picture on the right hand, side or it may be, a co-op server which is uh not discussed in this slide.

C

So this is a one and a half round trip for the protocol, and if you want to use oscore, you could either complete the two round trips and then start the oscore request response over co-op or you could include the score request response in the second round trip, as is discussed in this draft referenced here, which is proposed for core, and that basically gives you. The ad hoc authenticated key exchange and oscar first oscore request response in two round trips, and the last bullet just shows how you get the oscar security.

C

Con security context out of the ad hoc protocol, so oscar needs a master secret and two identifiers, and they are provided as described here and the algorithms for oscor was negotiated. So you just pick the selected cypher suite okay.

C

uh So there's a comment from john here on the on the only the x coordinate of g x.

D

C

That's right so that that's that's a good point that you don't need the same question. Oh!

C

Oh sorry, I missed a lot of in the chat I'll get back to that. Sorry! Go on to the next slide!.

C

uh This is the final slide here um and then you can take questions, so there is a as was announced in in the responses to the adoption call. A lot of people are working on implementations.

C

That's I just mentioned a few here. Martin dish has made a rust implementation, which is openly available as part of his oscar implementation.

C

Stefan ristisov has made a he has actually implemented all methods in microcontrollers and also some different implementations using armed trust zone, and it has made some performance measurements on that which he's uh working on publishing and also his code uh is planned to be open sourced, but I um yeah we have to ask stefan would state this on that universe of mercy. Mercia have been doing uh ad hoc implementations for a long time, and the current contact point is: is edward ingles.

C

There is also c plus programming program in in the old ad hoc repo for generating test vectors, uh so that that concludes the presentation. Are there any questions.

A

Yeah, so if somebody has a question, then just jump in the line.

E

uh Yeah, so I wanted to check on the sense of the additional data uh because I think we've gone.

F

Straight back and forth between a couple different things for the message two, and if I remember correctly from the slide, it was showing up within the blue box that was supposed to be in the xor encryption.

F

um Could you just confirm that the the additional data is covered under the encryption and if it's also covered under the macro signature.

C

uh Let's see now, the the additional data is also included in the external iad. I think I need to look at that. I don't know I don't off the top of my head.

C

D

C

A good point: yes yeah, so, yes, your concern was whether you could actually make changes or what was the concern.

F

uh I was just trying to make sure I remembered what we ended up with, because I think we had talked about more than one variant over time and I had forgotten which one we decided to use, at least for now.

C

Right so so um yeah, I I don't have the draft in front of them. I need to look it up. Okay,.

F

C

On the list right, but basically um the the intent here is the security guarantees provided for the additional for the auxiliary data is that we have actually no guarantees for for 81 and for 82. We we don't know it's. We cannot say it's confidential because it depends on. I mean you, don't know who starts this protocol or who is involved before you actually get to message? Three, so 83 could be encrypted and and integrity protected, but 82 doesn't really have any um at least no confidentiality guarantees.

C

I have to look up the integrity, okay thanks so just to get onto that. I don't know that particular example in that particular example uh in the draft uh with auxiliary data and third party authorization. In that case, the auxiliary data is basically a a mac. So it's a truncated mac, eight bytes, truncated mac. That's the content in that example.

F

Okay, we have any other questions.

E

D

uh Yeah, this is daniel ben. I think the answer to your question about whether the ad is included. Is that there's a transcript? Can you go to the next slide here.

D

D

Well, I I don't know how to tell you which side to go to uh sorry.

D

Yeah there is a transcript hash. um There you go yeah that one the the float right there. The th2 should include the hash of the messages which should include the um uh the additional data. If that makes sense,.

C

That's right, that's correct!.

F

Okay right that you both get the same thing by putting it in the key schedule. But at the time you don't necessarily know who sent it and that maybe, and you can't send like fully you can send data in it that you don't want to be public because you haven't authenticated the other party. Yet.

D

For ad1 and maybe 82 but it'll, be three pv: save yeah.

F

Anyway, I didn't want to spend too much.

B

A

If I could ask people to please say your name before you ask a question just for the audio record, I guess it's, that's the. What.

B

You want to go ahead or.

G

Yeah go ahead. Hi. Can you hear me? Yes, uh okay, uh so uh could you go back a few slides where there's this explanation on uh this method, car or like what happens, uh the the initiator is uh suggesting, like I'm trying to understand. Is there any requirement on the initiator to know what kind of authentication it expects from the responder, especially if it has rpk psk certificates uh like? Could you explain that part again? I wasn't sure like.

G

If I understand what happens if there are multiple credentials and does the initiator need to know or indicate what it expects from the responder.

C

Yeah currently, there is no no negotiation or information sharing on methods here, so this this assumes that the initiator knows whether the responder is going to use a signature or a static default monkey. That's basically what it needs to know and- and there is an option if we want and that's that we provide use the same type of error flow as for cypher suites, to provide further information about methods, but that's not currently included.

C

Does that answer your question.

G

uh Yeah yeah, I think that's that's something for you to consider if it's worth adding and also also the case where maybe the initiator has several credentials, especially if I think of group scenarios where, in some cases you might want to like identify that someone is a member of the group or then individually identify that initiator.

G

Then you might want to like have some kind of error flow for con cases where, like you, can tell the initiator that maybe psk is not good enough and you need to use uh certificate based authentication, for example,.

C

Yeah, so the current just to clarify the current uh assumption is that we are only using asymmetric protocol here, so so psk based authentication is out of scope uh for for for the initial scope, but it is the option between signature and diff and and static different helmet, that's currently uh unknown to the initiator when it comes to identification, how to get the um the credential.

C

That's that's provided in the id cred r, so that that should be the um either the raw public key itself or an identifier to something that you could fetch the public key. But currently there is only the case: either signature or static difficult. So I don't. I don't know if the what the group setting would be.

C

If I understand your right would be that you actually have you have multiple and you want the responder to choose or why. Why would you give an example when you need to provide to open up for for.

G

Multiple, I guess, if you don't support psk, then it doesn't really uh make a difference, but in in case there was this psk, then it might be the case that for certain operations you just want to verify that the node is a member of the group and maybe like the psk that is configured for the group is fine, but for some other operations you want to identify the device and individually and want to use certificates.

C

Okay, sorry so yeah, so you were thinking of yeah more, like group type, that's explicit, excluded from the requirements actually group type. This is strictly uh peer-to-peer.

C

G

Don't think that's.

C

G

No that that that's fine, just clarifying since, since we have time on the agenda, uh thank you also. Maybe another question was about.

G

You mentioned that the device or the initiator can use a221ar certificate, yes, as authentication credentials, and then you also mentioned later on in this- that you can uh like combine the enrollment in this auxiliary data. So I'm wondering like is the goal that you start with the certificate and then get another certificate or like enroll another certificate or.

C

Yes, that's one one scenario that you start with say that the manufacturer built in credentials, so you in the factory you provision a a. um I think it's called idev id, which is the signed by the manufacturer, and then when this device is being provisioned and being commissioned being deployed in a network, then you want to enroll a an operator or a network, a network operator certificate.

C

So then you, you would authenticate with one certificate and you would for the purpose of enrolling a second certificate and just just to add to that um in neither of those certificates need to be transported over the constrained link.

C

So you could, both in the case when you authenticate you could provide a reference and the result of the enrollment could also be a reference going back to the device. So the only thing you have is your pilot, your public key. Of course you need to have your key pair on the device, but certificates stay out of the constraint links and that's the type of scenario where you want to where you may want to use your auxiliary data to integrate enrollment with authentication, okay, yeah. Okay, exactly.

B

Thank you thank you yeah, and we have one more question from ben. I guess.

F

uh Yeah just to follow up on the latest bit so when you're, using a reference to the certificate, would that be possible for the device to never actually have to de-reference the reference to its own certificate and just sort of get back. So it gets back a uri, and it knows that that uri corresponds to its own certificate.

F

uh But when it goes to talk to other things, it can just always send that uri and it doesn't ever need to retrieve its own certificate.

C

In principle, yes, that that's been- I mean I this, has this not specific? This is not specified yet, but these are.

F

Yeah yeah, it was just a wild and crazy thought that occurred to me right. As the previous question was going on.

C

Yes, that exactly that is the intent. Yes, thanks.

B

Okay, so I guess we should. We are a bit over time, so uh I guess we should conclude now stephen. What do you think uh one more in the queue? Oh there's one more! Thank you! Yes, okay! Let's take that one.

A

Yeah we have another presentation on issues so we'll be encouraging people to open issues and get up, but yeah go ahead.

H

Hello, can you hear me? Yes, yesterday uh hi, um I have a question I think regarding the previous one with muay thai and it's a it's a purely a deployment scenario.

H

So I understand that you know it could be a manufacturer signed 802.81 air certificate, but you know many practical scenarios right say, for example, I may buy a device. Then I activate that after one year and if the certificate is invalid uh is that that protocol there is any way before the you know, operator certificate is assigned. There is any way to actually verify or bootstrap that device.

C

So the revocation of credentials used in the protocol is is not excluded from the requirements, but it's we are. We are only going to look at certain simple cases for for verifying validity or credentials.

C

uh That's in at least in the initial scope, and I I don't know exactly- I don't have an answer to your question- uh how this will handle it specifically, um but I can imagine that you could have that type of some sort of revocation related information, uh but I mean it's a hard question: what what happens to the device if, if the the only credential assuming this is the only credential it's using and it's expired, then of course that's a problem for for using that device in general yeah.

C

I don't really know how you would solve that in this protocol.

H

Yeah so yeah, I understand, I think it's possibly. I was just curious right because I think that it's not that it may not be expired right, but you know that there are lots of lots of you know companies they produce the device manufacturer and then companies sold, and you know there could be a lot of other things right so from a consumer perspective right, you know whether there will be a way to actually would stop that device.

H

So that's- uh and I understand that these are the scenarios difficult to you know, cover all the scenarios, but uh um it just you know, I'm curious that whether you thought about that.

C

um No, I don't have any, I mean I don't have anything more than than you know. I said yes, no, so sorry good thanks.

A

Okay, so we take one more 10 million. I think you're up there so go ahead.

I

Hello, hey, I I wonder that the republican will be used for signature or encryption.

C

What the republic is used for.

I

C

Yes, so so it's it's used.

C

If it's a rob, if the raw public key may either be a public signature, key in which it's used for signing uh or it's used, uh is it's a static, diffie-hellman key, in which case it's used to generate the shared secret which is used in the key scheme, this colorful picture, key hierarchy and and to create the keys, derive the keys used for encryption and mac.

C

So that's that's where the raw public key goes.

C

Did that answer your question.

I

Yes, I got okay.

B

Thanks, okay, so let's conclude then and go to the next item in the agenda, which is uh the open issues of the ad hoc draft, so I will switch the slides joram. You are again the presenter.

C

Yes, sorry about that, no yeah, so yeah, no okay! So next slide. Please.

C

So, yes, we have started to compile open issues. We are using the lake repo, the lake working group, github repository, which you see the link here and the currently. It's only three issues based on the comments we've got so far and yeah and then there's at the end there's some next steps also, but let's go for the three open issues next slide, please.

C

So the first yellow was a straightforward comment by martin dish. He thought that reading cozy was. He didn't want to read too much of cozy to implement ad hoc, and we have already subsection in appendix a speaking about cosy and we can definitely expand that on on cosy, sign and cosy encrypt without duplicating the specifications. So, yes, we should do that next slide. Please.

C

This was a comment by rene stroik uh why we are enforcing both shaft iron 12 and shaw 256. So the setting is this that the cipher suite zero and one includes ed25519, which specifies shaw 512, but we also as explicitly the hash functions used. We also require 256, because that's that's typically what you would use with uh with with this uh setup.

C

So the question so we're actually mandating both and the question is: what should we do about that and I think some some people can with bear witness about the problems related to that, and that would be great if people could could comment and provide input.

C

But the options I see is basically either we we don't change, we require both or we change the hash algorithm to five sharp art 12, but in practice I, I suppose that the limitations come from uh that hardware. Support already provides sha 2556, so just changing here to.

C

Would make it look like a um less of a requirement, but you still it doesn't really solve the problem, and then there has been discussions about uh ed25509 with shot 256 and I'm not really up to date with all uh with. What's the latest date there, but just strictly speaking from an iot point of view, I mean this type of implementation and constrained device.

C

If you want the adwords curves to be deployed, then having a specification with short 256 instead of shaft 512 would ease the implementation, I think so maybe someone can add, add to this.

C

I think malicia you had some some ideas on hardware.

B

This is malicious speaking, so most of the hardware I've seen implements sha 256 and I think it's from the implementation point of view. It's important that we converge on a single algorithm to use uh so either option two or option. Three, I think, seems the most feasible, but for option three, I'm not familiar with the current state of the development of the documents, so maybe someone could chime in there, but essentially the bottom line is. I would like to see a single algorithm that we converge in a single algorithm, hash algorithm to.

B

A

Sabre are you in in the queue to talk on this point or just still, in the queue.

H

Oh sorry, stephen did you ask me.

A

uh I asked super yes, I I don't know who spoke there.

H

Yes, yes, I I did speak earlier. So thanks.

A

Okay, so I can kick you out the queue okay.

A

Okay, so I guess we're resolving this issue, or it probably needs some some discussion on the mailing list and maybe checking with the uh cforg, particularly if option three was ours. No.

A

Hit with europe.

G

Yeah, uh I was just also writing in in the java chart, so this is something we encountered a while back uh in six law and uh thanks to renee. uh I think we have solved this issue, so I I would put a link to a couple of drafts on on how we have done it in six low working groups. So basically we use a different representation convention for the same curve.

G

So the curve is still two five, five one nine, but instead of the edwards compressed, if you use the weight truss, then you can use uh sha-256.

A

Okay, that certainly sounds like something to run past cfrg at some point, in indeed,.

G

So that that's the plan for the elvik draft, which renee has written, I mean it- has already undergone last call second reviews and so on, but we agreed with the a ad that, when the idf last call is issued, cfrg would would also be informed of this, and this is something again, I'm not familiar with all the nist specifications, but renee seems to follow them. So this is something also in the latest nist 800, something something I can't remember. The exact document number sure, but I mean.

A

I I think people should be aware: there's there's, there's probably a non-zero probability that that redefining 25519 with chat256 is something that does not turn out to be a good idea. So I wouldn't the fact that something is in a flash call. That assumes that does not necessarily mean it will happen. I think that that's something to be aware of and the discussion with cfrg would need to happen.

G

Sure yeah make sense.

C

Okay, thanks for the input, could you please put your references in the in the issue?

C

Would that be possible? Is the lake working group github issue.

B

Sure, yeah, okay. So let's write down in the minutes in the action point for this to comment on the issues for my hit to put in the documents in the comment section.

C

Or anyone that has input here, please provide.

B

Questions yes, and let's continue on this discussion on the mailing list, then.

C

B

C

Slide there are no other.

B

If there are no.

C

Other comments.

B

I suppose I see none.

C

Right: okay, next slide, please.

C

uh Right, so this is uh a slide with too much text. Unfortunately, it probably complicates the issue more than it solves, but we have an agreement uh in the requirements uh that we should not uh include psk ecdhe in the initial scope. uh This is currently in the draft, but we need to take it out. So we need to replace that and I think we need to first discuss a little bit more what we need to replace it with and that's the actions there.

C

We need to take a step back and think about what other practical attacks on iot settings that we need to handle uh with with, for example, with some symmetric key scheme, uh we had a discussion initially, that's a mail thread reference which looked at how to provide uh forward secrecy uh without divi helmet. It was a psk symmetric, key based scheme, but that was just a starting point and it didn't really look at at the problem. It looked more like it.

C

This is a this is a lightweight solution, so I think we need to retract this and get back to the actual problem statement.

C

um But in this context there are a lot of things to think about, for example, protection of long-term keys compared to session keys and and passive or active attack, for example, and there's also some interesting ideas coming out of this thread.

C

I mentioned above like, for example, doing uh key rotation within the session, so that you don't need to take down a session to to change keys, because you could do it if it's based on sequence numbers and we in all square, for example, we already have sequence numbers, then the client and server knows when to change change keys.

C

So I don't uh I'm not sure, I'm making this very clear now, but I think we need. Basically, we need to restart. We need to take out the pskhg, that's clear from the requirements and exactly what we're going to replace it with needs further discussion um so and I'll I'll start that thread again on the email list, and that was the last issue next slide. Please.

C

So next steps submitting a new version without psk is esdt. I plan to do that on my plane home and then we have today which we should talk about now. The the tamarind verification and all the considerations from that which we need to take care of there is also an old repo with issues we need to go through that and see what are relevant still not only listing issues. We need to fix issues too, and we are welcoming more reviews and at some point we should should plan the plug tests between implementations.

C

Okay, that's it.

B

Thanks joran, so I guess so, let's write down in the minutes that the action point for you is to uh start the discussion on the uh on this issue. Issue number three.

C

B

Yeah, so I just missed mentioning that and then with that we are open to take any questions you might have. Do we have anyone in the queue.

A

No, but I would encourage people to open issues if you're opening an issue on github. um You know if it's, if it's an editorial or a name or something then just doing it on github is fine. But if it's a substantive issue, please also send the mail to the list um and yeah we'll have to watch where this question happens, on github or and or on the mailing list.

A

But I would encourage people to use the issue tracker and get up and create issues there and then start related list. Discussion for non-trivial ones does does any. Has anybody who's read? The draft got any other issues that they might want to not formally raise now, but bring up in audio at the moment.

A

This is a good time if you have.

A

And again you don't, I don't see anybody in the queue so we'll probably move ahead to the next one. There's.

D

A

Should be time for aob at the end, if you, if you're having to read the draft now, I'm gonna come back to some issue at the end of the next presentation. That's perfectly fine.

B

Yeah- and I guess we'll hear more about the second point here- on issues based on the tamarind model by car in a little bit yeah.

B

So with that, let's conclude that uh agenda item and let's skip to the last uh slot before I uh before any other business, uh which is the formal analysis of ad hoc by carl uh carl, uh can do you hear us yeah and we we see you uh hi. Can you hear me yeah yeah? We hear you and let's just say next slide when you want me to flip, please: oh yes,.

J

Thanks, uh okay, so this is a sort of progress report on the formal analysis of ethel that we have been working on and we fixed the version from 1st of march.

J

So there will be some discrepancies compared to what joran just talked about, but we get to that and if you are interested in reading sort of the current version of the report, you have the link here on this page.

J

Okay. Next, please.

J

So this is joint work between me and vaishnavi and alessandro, and it's partially sponsored by the lost program. Next, please.

J

So first I give a quick overview of for analysis and the tamarind tool. Just in case there is someone who is not sort of in blood and then I'll give a quick overview of the framework, as we view it and what we have analyzed and then I'll go into the analysis itself give an overview. And then I will dig into two technical details which I think might be the most interesting.

D

J

Technical aspects that we found next piece.

J

So formal analysis roughly what this is that your model protocol in some you know mathematical, mathematical formalism, and then you encode the requirements and the goals that you want to sort of learn about this protocol.

J

In some logic, and then you try to prove them for that model, and preferably you do it with some tool that can help check, checking your thinking so that you don't make mistakes, and this is a useful process to do at least, I believe, because the modeling itself and and the sort of proving the work you do with a lot of hidden assumptions and inconsistencies and complete requirements and vulnerabilities and so on. As you move along the proof that you end up in the end with is maybe not so interesting in itself.

J

But the sort of process will read a lot of interesting stuff along the way um and it forces you to really consider what type of attacker are you trying to protect against and also just again specifying things uh clarify what you're talking about when you write sort of protocol specifications in prose? It's very sort of easy to to imagine that that you have the same understanding within a group but about how it works. But what actually you might have different ideas and the more precisely the better.

J

Of course what it does not do, and this is that it will never be sort of a proof that the protocol is secure, um because it's not even clear what is secure means.

J

So so what it does is that it sort of splits things up in smaller properties and show that some certain property hold in that model of, but also it is need to understand that there's a huge difference between the model and the actual protocol. uh The model might have missed stuff that that the protocol is not uh is doing. It might have sort of missed the attacker capabilities that you later find interesting to cover.

J

uh You might have missed properties you want to show, or while you're doing the modeling you might abstract away. The details of the port code are actually important. So so that means that you cannot just get the sort of stamp saying is secured when you're done, but you get more detailed knowledge and higher assurance level of the protocol.

J

J

So the tamarind tool itself- this is a very super, simplified uh view of what it does, but essentially you define the the the protocol as a kind of description of the the roles the initiation responder. Then you sort of describe what the attacker can.

J

Do you put that into some into a modern definition, which is a kind of a parallel function program if you like, and from that time, tamarind will regenerate uh conceptually all possible executions, all of these agents and attackers uh and and then you, you define the properties in intel style, logic and and you sort of very tamarind will help you prove that, uh where these properties hold overall choices or not or whether you exist to certain traits with some property that you're interested in yeah.

J

So that's on a very high level of what is going on conceptually uh next piece.

J

So the other framework, uh so essentially, there are many way different ways to look at it.

J

But essentially, I think we can view it as a sort of it follows the noise framework, uh with addition that you know also the possibility to use signatures for uh authentication uh which is not yet supported in the noise framework as not the version I I found on the noise homepage, and this means that we get when both parts use and signatures means as we get into a sigma style protocol, and it's very very close to to see my but not exactly the same, um and then, of course also advocates these encodings, like course, and sql all those kind of things.

J

But but we have not modeled that level of detail in tamarind.

J

Erdog also reduces this challenge, response, signature, sort of way of working for the stat methods and the stat methods, or just did this static, different monkey things that euron talked about earlier uh and it uses this transcript hash, where we are working like the glasses and uses d to the x y as the uh session key material, essentially um not really because ad hoc sort of outputs, the the state which the hkdf can then use to extract session keys from, but what gives sort of the secrecy and the authentication properties, or is this d to the x y or d to the I y or little r x, if you're, using the uh stat based methods?

J

Instead, this message looks like opti-less, we'll see more about that later on um and so forth. It's a bit unclear whether it's an exact mapping to noise extended with the signatures. uh It's a bit sort of both the noise specification and the uh error specification are very pro slides. So it's difficult to see exactly whether the correct parameters goes um where they should.

J

uh Luckily, there's this noise explorer uh work, which is formalizing the the nose protocol more, and I think it would be easy probably to to try to against that formal specification to see whether the mapping is exact so to speak.

J

um I've got to all know that the sort of cryptographic course that occurs is well understood constructions, uh and if we sort of look at what are the main methods that would be of interest, I believe there might be some solutions with this start saying and saying start methods, and that is where one part is using uh static. Different monkey and the other part is using a signature, because this is kind of a mix of or existing things.

J

All in all, we have more than all all the methods anyway, just to be on the safe side. uh Next piece.

J

So if we uh simplify the adhoc framework enormously, we end up with something like this.

J

Essentially, we have the initiator and responder and in the message number one, the ancient initiator sends g to the x to the responder and the responder uses its credential credit r to authenticate itself towards the initiator, and it also includes d to the I d to the y sorry for uh to generate the session key and then the session key is some kdf for odt to the xy and possibly something more and then a heads up here is that that I have simplified things.

J

So you should really read these as functions but more like the session key depends on the e2 xy, even though it says kf. So so it's more like dependencies that are interesting on this abstraction level uh next place.

J

So one could and you can take the next also, maybe at the same time, so one could view it as the first flight, uh m1 and m2 is sort of the authentication of the responded towards the initiator. But then you can also imagine that message. Number two is the first message of the second round where it's, the purpose is to in to authenticate the initiator towards the responder using the blue credit credential.

J

So so, in a sense that middle message is sort of serving both as the last message of one protocol and the first message of the second protocol, uh which is also kind of following that, the noise by your thinking um and the only difference in what so is the key session key material or what so we will contribute to the secrecy of the session.

J

Key material is that in the stat based method, with one of the boxes using static development key, then then the session key will also depend on the credential of that party and and again, if we think about uh old elasticity, it would essentially be since let's just have mutual authentication, it will be that the responders static key would be included into the sort of sequencing here components of the session key, but but for all other methods. It's just gtx y. That's the session key material.

J

J

So this is kind of a overview of what we have looked at.

J

So we have all five methods and the fifth method here, which is in addition to what john mentioned, is the psk method, which we also know, and that was present in the march version of the draft we were looking at and we have proved like the basic fundamental properties, authentication, bfs session, key independence and so on, and we are planning to start looking into a weak pcs as well as weak, post compromise security, and that means essentially that the adversary has temporary access to uh to using the long term credential.

J

For instance, you have access to a sim card tpm, but it doesn't actually read the long-term credential and the attacker is of course, able to attack all session keys generated from that as long as his access to the dpm. But when that access is revoked, then the future session keys are still secure. So that's the weak version- and I am pretty sure that holds the strong pcs will, of course not told, and the next thing we're trying to look into is kci resistance.

J

I'm pretty sure that also holds because it's based on sort of attack is based on unknown constructions. But not as much on that one as the big pcs until we have actually checked it.

J

um We also during this work. We identified some some missing considerations in in the draft, uh for instance, non-repudiation aspects and and so sort of whether you should think about teas and and session key reveal, queries and stuff, like that. We also run into one one, the unintended authentication confusion which is sort of a not so much problem with airdrop, but it's not sufficiently explored relation between advocate and its application. That's using adhoc so so that the api kind of needs to be a bit more looked into it.

J

And then also what is the actual? What should constitute the session key? The definition of that is also something that we believe should be. I must get more now come back to that. uh So the conclusion is that that'll build on on well-established components, and it seemed to behave as as one could expect.

J

Also all these different methods, though, have quite different security guarantees. uh So so, depending on which credential you choose, you will get sort of a different properties of the protocol and then one could sort of perhaps wish that that would be some baseline. That all method has these sort of basic properties, and then you might get something in addition, where one uses others and so on. But then we need to define exactly what would that that base set of properties be.

J

And this comes, I believe, wondered the fact that edoc is sort of established based on on it.

J

It should establish an oscar security context, uh but it sort of does that and see how good can you make that given some restrictions, but but then the actual use of the protocol is less well explored, which means that it's not so clear exactly which properties are the most ones that are important to to verify or check, and then we believe that if you're looking into like user stories or use cases or something try, try to to extract would be the most common and most important properties that that would sort of guide both the design of the protocol and the sort of what book.

J

There's verification workshop should focus on next. Please.

J

So uh before digging into to this session key authentication property, which we think was perhaps the most interesting finding uh just brief overview of the attacker model that we have considered so so we consider like a standalone attacker model. So the attacker can read all mysteries that are sent deconstruct them into their components, compose that into new messages and insert that and can delete messages and do all those kind of things and run an unlimited number of sessions.

J

And it also means that the uh we make sort of a perfect cryptography assumption that that encryption algorithm, for instance, is not possible to reverse. Unless you actually know the key.

J

So if you look at message number two, for instance, uh this encryption operation would mean that attacking would not be able to get hold of credit or unless he actually has the key used to encrypt that um so yeah that the next piece- and that's that's a well-known thing and the attack loss has the possibility to compromise parties uh after- and this is the model perfect for secrecy. So after the session is complete, complete the attacker can can compromise the long-term key and there's a mistake in the slide.

J

This sense that you also can completely compromise the session state, but uh we don't have sessions stage, reveal queries, but we do have a session key reveal queries, that's also to be able to model uh pfs and.

H

Secrecy actually.

J

Just basic, um we are working in the pre-specified peer model, and that means that both parties knows right around the protocol. uh Who would I want to talk to that's a fairly stumbled uh simplification?

J

uh We also assume that there is a one-to-one correspondence between the identity of uh the party and its uh public key or its uh um and his private key. So that means that the attacker cannot register a new public key for a a given identity.

J

That would already exist, and this is in line with that obvious assumption is assuming itself in the draft and it also simplify things we're using a symbolic drivability based notion of secrecy, so you're not looking at any type of observation, equivalence or distinguishability based security notions. So basically can the secrecy that depends on whether the attacker can actually derive a certain torment down the line term algebra, rather than trying to see what he can differentiate between different things, and we also use getting load style, authentication based on the corresponding correspondence properties, so over the traces.

J

And we assume that all non-compromised parts are honest and don't try to to that they do as the protocol prescribes. They don't try to cheat each other each other or do other strange things to themselves next, please.

J

So if we then look at uh what mean which version of session key the authentication we use, so we went for the something called injected agreement, and here it's going to be described in the sync method. So it means that the initiator is on using standard signatures to authenticate themselves to each other, and in this case, if you take next piece, we can see that what that means is that if the initiator receives message number two, then he can derive the session key as some function of g to x y.

J

But if that happens, he also knows that at some point in time, during this protocol run, the responder also is able to drive d to the x y and there's exactly one uh instance of that event that the responder derives d3xy.

J

So it means that both parties are, they agree on which key they have derived each of xy, but they, but the initiator also knows that there is exactly one uh instance of the responder running that runs. It cannot be the case. The attacker has fooled the responder, for instance, into to running believing that it has around two sessions or three sessions, which is not not the case that the attacker fully responded into, believing that the session gives t to the x cell for some said, for instance.

J

So so this is the injector agreement thing and, of course you can prove this also for other important, not only the session key, but for for, like for algorithm choices and at the adm, um 81 and 82, and so on, but not 81, but for for 82.

J

um and so on. But we have not modeled that yet, due to some um problems, we've been getting tamarind to terminate uh and then this uh this property that then, of course holds in the other direction as well. So the responder, when, if you look at the blow flow, when the responder authenticates initiator, what would happen is that when the responder gets the third message, it would know that there is a corresponding event on the initiative.

J

Side, which is unique, which also has sort of made the initiator derived right to x, y and understand holds for four methods. Except for for the case where the initiator uses the stacked method for authentication.

J

And this, if you take the next slide- and I will explain why this is- um is the case, and the reason is that the session key material is defined as c to the x y and t to the I y. So basically, there is a dependence. The key material sashing material depends on the.

J

Secret key of the initiator, and because we have this identity.

D

J

Or identity protection, it means that the responder doesn't know who it's talking to when it's sending message number two, and that means that it does not cannot possibly compute anything that depends on initiators either private or public key in any way.

J

So so that means that there is no guarantee for the initiator that the responder actually knew to the one, and in fact, if it did, it would be a problem for identity protection. So so we cannot get uh injected agreement on this keying material.

J

um So the next place um there are so yeah and next so that we don't have that. But what we proved instead is that you can have an implicit key authentication, and that means basically that if the initiator sends message number three, it knows that if the responder sees message number three, it's only the responder that can compute the session key and no one else can do it.

J

And what this gives us is essentially that the key key is we. The key will receive it, but there is no confirmation from the initiator that the responder actually has computed this key, which would be the case in the injective agreement property and whether that is needed or not. This depends on what the portal is going to be used for next piece, so we have come up with four alternatives: how to fix this, and there is probably more, if you put your mind to it, one would be to sort of uh accept this fact.

J

So you do include the dependencies on on the initiator's private key, and then you would accept that you have different authentication properties for for the different methods that feels a bit unsatisfying, because I think that's a kind of a fundamental thing. If, if you need key confirmation that that should not really depend on which credential you use, that that feels a bit unsettling um two, on the other hand, uh say: okay, let's exclude that that dependency and just run g to x y, also in this case, uh but then that is different.

J

It's uh differing from from what else is doing and if you look at the the simultaneous it's really carefully designed for for um for for ck style model, wherever you have session state tricky, repeat, queries, and I mean it. It feels unnecessary to slope that property away just to get to harmonize across all the ad-hoc methods, so this one doesn't either feel very nice.

J

uh The third one we need to include a fourth message from r2i include a mac based on a key derived from the key material, but it can't be from the same branch as the actual session key, because the mirrors key in distinguishability, if one would like to prove that in some computation model later on- and this of course is not so nice either for the applications, because now they would need a fourth message, which is not preferable, which leaves us with the fourth message method.

J

Our fourth idea would be to include the initiator's id in message number one, and what happens then is that that removes identity, protection for the initiator, and that is not so nice either. But one could also consider that there is discussion in the eric drafter that sort of the roles can be reversed.

J

So so, if there is some entry that that really should have identity protection, one could uh consider reversing the rules and having that role, necessarily that that entity acting as respondents instead of initiator, there could be situations without diplomatic also, though, because it might require, like an initial trigger message, just to kick off the protocol. So it's not clear. That's a perfect solution either, uh which brings us to the post two bullets and the first one, which is unfortunately uh cut a bit short. Is that without better understanding the protocol goes?

J

Selecting between these alternatives is difficult. uh It should say um which I believe it is. That needs to be a trade-off made somehow, and then one could also consider that, if that trade of, when it's made should have been made, be aligned across all methods that have the same property of all methods.

J

If you consider this to be a very important property, so that I think is one thing that could be discussed as an issue and this also sort of connects to to uh both sort of how to which how to select the key material but also which kind of properties do we want to have and how will harmonize between methods, uh and I believe that this will lie up.

J

So um if you have any questions, I I've seen that scrolling a few questions on this chat, but I haven't been able to follow that. Unfortunately,.

A

Yeah. Thank you thanks, carl. If people have questions now is the time to jump in the queue.

A

There's a bunch of chad and jabber, but apparently not resulting in audio questions I'll give them a minute. uh So I have a question carol. uh uh Is there a kind of a plan for how to wrap up this kind of uh excellent kind of theory, work and and uh proofs, and so on, in terms of getting published, getting peer reviewed having other teams that we know of doing the same thing? How long might it all take?

A

um What's your kind of thought, I'm not asking for precise answers right now, but what's kind of the general plan would you say uh yeah so.

J

We put it on on archive and then of course we are very thankful if anyone has time to review anything there um and the link is on the first slide, but then we are planning to submit it to the conference, which I the deadlines in august.

J

Yes, so so we will sort of wrap this up and polish it up a bit and then submit it and see what happens and I'm not aware of anyone doing tamarind modelling on this.

J

Or pro various modeling either actually.

A

Okay and more work, yeah more work is always welcome, so so, okay, so it's not a you're you're, not thinking of this taking another six months, you're thinking of this work being kind of done, soonish and maybe have to be redone after the protocol is finalized or something is that roughly a plan yeah.

J

So I mean one of the problems: is that we've been running out of memory quite a bit with tamarind, so I'm trying to secure a machine with more memory and so that it was in the current sort of roadblock.

J

But but I'm working on that, and that is just one way. I think we should be able to prove.

D

J

Property step that we were want to look at um and then I guess it would also be interesting to start looking into computational proofs as well. At some point great yeah, okay,.

K

They have to buy us hello device come in here. Can you hear me? Yes got it? Okay, uh I have questions on slides, 19.

K

K

um Do you, like you, say if m3 reaches responder, only the responder session will be able to complete session key? Do you want to say only if m3 image has been responding.

J

Also, can we look at the slide? It sounds like very specific wording here, so I just want to make sure I get it.

K

Right, yes, that one, I'm I'm not 100 sure. If I understand what you're saying there, um though, if m3 reaches the responder, only the responder will complete the session key. Or do you actually want to say only if m3 reaches the responder the responder session.

J

Oh, it's actually actually both. So what one is like, if I understand your question correctly, one one is the sort of security part that that it's only a respondent can compute it and no one else, so so that that is true. But it's also, of course, true that that, if the message doesn't really respond, reach to respond, the respondent will not be able to compute.

K

Is also able to compute the session.

J

A

A

Okay, any other questions uh on this presentation.

A

And uh okay, thanks carl uh thanks for cutting's work, and I guess at some point somebody will try and translate some of these uh issues. You found into issues in github and we can process them there. So yeah that'll be great.

A

C

Yeah, yes, just confirming yes, I'm gonna go through the paper and and make issues out of the comments uh and feedback we got there.

A

Fantastic good stuff.

A

Okay, thanks carl, uh I guess we can move to the any other business part and somebody wants to go back and ask questions about this. That's just fine too! We can kick you off to video for now. um Okay, so we're now at the any other business part of the agenda.

A

Does anybody have other business that they would like to bring up right now we have like 20 minutes so lots of other businesses possible.

A

F

Yes, then I'll just uh repeat my usual plug that we do have this gather dot, town sort of informal, hallway environment that people could migrate to after the session and have any conversations that she would have had in the hallway. If we were in person in madrid, so it would be good to get a lot of people there sort of have the critical mass going and you can say hi to the friends you haven't caught up with yet or that sort of thing.

F

So that's it just to plug for gathering.com.

A

Great thanks, uh I did have one one piece of other business which I put in the chat earlier is: uh how have people got thoughts as to how they want to proceed from here? Virtual meetings, wait until there's enough issues in the issue. Tracker do something in september.

A

What's what you people like to do.

A

C

Correct yeah you're on here um yeah. I think I think the virtual meeting would be great. I mean we have seen some ideas coming out here uh from on the in the chat and I think we'll have some more um input on after the the issues uh are are more tracked, so um yeah how about mid-september or late september. Would that be a good time for for an interim.

C

Right yeah so um well, my proposal was just yes, yes, virtual interim. That was what I wanted to say and, and the date we can discuss but september is good uh not in the beginning, but in the end or in the middle, and I see michael, have some input as well on the on the jabber.

A

Yeah so michael uh basically is also suggesting meeting in september virtual interest but and also said consider a hackathon online.

A

um So you mentioned, there are multiple implementations. Is there? Are people able to interrupt on tests with one another? Are they doing that already do? They would organizing an event like a hackathon or something help them do that and when so, when.

C

Yeah, I I don't know I mean there are a number of implementations which are, are, I suppose, almost ready for that, but I we have to check with the other implementers and see what what's going on. um I don't know at least for progressing the spec. I think we need to have a virtual meeting at some point before the next itf.

A

Which may well be virtual also so, okay, we're looking at sort of the suggestions mid to late september. I guess we can create some kind of poll to see what dates people have, as a preference of that, I presume we're talking like a one two hour meeting.

C

Yeah, I I assume that we have some some new proposals on the table based on the discussion we had today and and what's going to happen in the next uh month, uh or at least I mean what will happen in the beginning of september- probably first half of september. So if we have something in the end of september, I think we'll have we have material to discuss and uh how we do with implementations is perhaps independent of that. So I think we could have a separate sec sort of a discussion on that uh independently.

A

Okay and then so, if we're talking about late september, then you're going to your plan is to reist. You know to put out a new draft that takes out the um the psk ecbh option and that that'll be in the next short. While I guess right.

C

That should happen soon. That will happen soon, but then we need to add something instead and that's that's still to be discussed, and then we have some other feedbacks from from from carl here and and and his team and yeah we're also expecting something from the the other formal verification team uh which kartik announced, but I don't know when so that's also something that might come in here.

C

But I think anyway, that the timeline ends september is reasonable for something to discuss, and even if we don't like know right now, exactly what we're going to talk about. Okay,.

A

So we can follow that, and so I guess the implicit in that is we're asking other participants in the working group to kind of. Maybe you know don't bother with the zero zero draft for now, but there'll be a zero one very shortly, and please read that and raise issues based on that. I think that's what we're asking right. Yes, yes, yeah! Okay!

A

So when you get that to the list, then uh we can make that ass explicitly and then maybe encourage people to try and raise issues between now and and a couple of weeks before the virtual interim- and we send a poll for that in the next one.

A

Okay, that's all I had is there. I don't see anybody else in the queue again we're in the angular business section for the next uh going going gone amount of time. So anybody else want to raise our issues.

A

If not ben has posted the gather town link into the uh java room and you can head off there or after you've gotten a coffee or something, and so thanks scott. Yes,.

A

Scott, your europe, I can see your video.

A

A

Audio, so it's give scott a second in case that was.

A

A oh god has left the room. Okay, I think that means that we're we're done for today, thanks to all the presenters um thanks people for all the chat and jabber, which is good to send out the minutes. We'll set up a poll- and I guess we'll talk next time sometime in sometime late in september, wish you anything else. Sorry, no! Nothing! On my side, I guess that concludes the meeting great thanks all and see you at the next virtual effort, whatever that is, which could be this gallery term. Thanks, bye,.

A

A