Internet Engineering Task Force Interim Meetings, 28 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: LAKE WG Interim Meeting, 2021-01-28

Description

LAKE WG Interim Meeting, 2021-01-28

A

Good welcome to the lake working group virtual meeting, um I'm stephen farrell, my co-chair is militia, say hi militia hello. Everyone.

A

So I hope my screen is displaying uh it'll be good. If peop somebody would confirm that, but I presume it is.

B

Yeah, I would complete whatever.

A

Right so on that you see sure names, charter, mailing list, jabber room, coordinates, uh meeting link for this meeting and the etherpad we have notetakers, garan and tim, I think, have agreed to take notes in the etherpad thanks for that we can keep an eye on the jabber room or ourselves as chairs. I guess- and we have the no well so this is the pointers to various bits of the ietf policy.

A

uh If you're not familiar with this, you should get familiar with it and all of the tips and here's our agenda, so administrative we're doing, um I think francesca is- is able to actually do the presentation on the interop session.

A

She wasn't expecting to be here, but now has made it then chairs, but ready militia and karthik will talk about the formal analysis and uranus john. I guess will run us through our open issues and then we'll at the end, just kind of as a part of the wrap-up think about what we want to get done for itf-110, um etc, and then I need a business.

A

So let's just do the agenda. Does anybody want to to change something in the agenda? The order, the timing, anything else now's the time if you have something.

A

Looks fine, okay, good, um so one other issue, I guess we should have put in the slides. We didn't um if you in the webex chat. If you want to join the queue to grab the microphone, uh we'll use the usual convention or what's becoming the usual convention. Now is, if you type plus q, if you want to join the mic line and minuscu to leave, if whatever you wanted to ask, has actually been handled already.

A

um So again, please use the jabber room for general chat, mostly use the webex chat for joining or leaving the mic line, and I think with that, we'll move on to the second set of presentations. So give me one.

A

A

A

C

Thanks this is the report from the second interoperability testing of edoc next slide. Please. So we had our second session, the 22nd of january of this month. um This time we had three implementations that were tested against each other. Last time we had two and thirteen attendees, which is much more than last time, um and I also collected uh some detailed notes and detailed reporting in at this at this link.

C

So you can take a look if you're interested- and I also wanted to point out that this interrupt was also based on version two of the draft, and there has been some updates since then.

C

Next slide, please, the more in details. We started by uh testing the do testing based on the test vectors on appendix b1, which is the one with signature, authentication x509 certificate, so the method is zero and the selected cipher suite that was used by the implementers is also zero, with the algorithm mentioned here and differently from last time.

C

This time we also the implementers also generated the some ephemeral keys, which are real ephemeral keys and not the values taken from the test vectors, and this was a great success because it passed with all implementations in all directions.

C

So that was really really great and next slide. Please, and we also started the last 10 minutes or 50 minutes uh to test on a test vector for appendix b2, which is the one based on error. Code indicated with static, difficult monkeys and the method is method number three and the same selected, cipher suites.

C

But so we started the testing. But there was some um yeah verification failure, and so we stopped there and we didn't even manage to test all possible all possible directions.

C

Blight so um yes, I also wanted to mention. We had some implementers that had implemented older cypher suites, so michelle veget has provided additional traces for method, 0 cypher suite 5. So if anybody has that has implemented that cypher suite and that method, they can also compare, and it will be interesting to hear- and also we got again good feedback from the implementers that should be incorporated into draft, um and we have also had more um communication with other implementers that are interested in participating.

C

So we will probably continue with this uh interoperability planning, testing and yeah continue appendix 2 and then other methods and cypher suites. I think that was my last.

D

Slide, maybe you should mention there were yeah. There were actually two more teams represented at the at the meeting and uh there is another another implementation ongoing as well so and other. Yet others are welcome so that we know.

C

I mentioned that there were 13 attendees, and some of these attendees were also also had other implementations, but uh we didn't test them in this.

A

That's right, actually that was going to be. My question was the discrepancy between 3 and 13 was a was a puzzle. um So it's good to hear um and thanks everybody for doing that. I I do have francesca. Can you talk a little bit about um just the the setup that, where people in different time zones, how did you get it to work? How did it work just mostly thinking about how we, you know how we can improve things for future uh yeah.

C

You might have seen that I set up a doodle that I sent to the mailing list and then I also nudged the implementers that had contacted us or offline or had participated before to please answer and that's how the the time was selected.

C

um So it's really based on implementers that want to participate and then try to facilitate so that it's the best option for everybody.

A

But in this instance, where most of them in similar time zones, there was no big gap or.

C

Yeah exactly yes, we were all in the same.

A

And were people, was it synchronous, mixture of synchronous and asynchronous um in terms of people being online at once or.

C

Actually, actually, there was michael was also in the in the thread, but he didn't manage to join. um So I was saying, like everybody is in the same time zone well, except one who didn't manage to join, um but otherwise, yes, we were all online at the same time and we were all testing.

C

So we were let's say um I was observing. We were observers while the implementers were testing against each other, and we were also gathering the feedback as authors, but yeah it's much simpler to do this uh online, so all at the same time,.

A

D

Steven, I don't know, I'm sorry steven go ahead.

A

Now, after you, I just got to ask anybody other questions so far.

D

All right, sorry, um so yeah I mean I don't know if that was what you were asking for, but basically they were. They were pinging between pinging and then running co-op. So that was basically how the uh and that advocate on top. That was basically how it was set up and and uh and poor michelle. He was in canada and he actually didn't go got the round to test, because no one had implemented cypher suite five, but all the others were in europe. So it was germany, belgium and sweden. I think was testing.

A

So I guess in jabber michael, is asking um or he's commenting that the time zone was okay, but he did his code wasn't ready, but he's he's asking to maybe try and plan this. I guess two meetings ahead for timing purposes, so he can know when to prioritize coding.

A

So I guess that's a request to try and schedule the next and the one after.

A

If that makes sense,.

C

A

Okay, any other questions, comments, uh requests.

A

Not hearing anything, so I guess we can move on and if people are interested just start by sending a mail to the list francesca, I guess yeah.

C

A

Great stuff and thanks everybody for the words good stuff so we'll move on, uh I guess malaysia and and you've got slides. I think.

E

Yeah yeah, so I can take over, we don't have any slides prepared. This is just more.

E

uh This is more to inform the working group, so I mean I will leave this both as the chair and the uh the participants of the meeting we uh we had with kathy and then can fill me in if he's still online, uh essentially as shares of the working group, we want to ensure that the that the specifications that we produce are high quality and since we are in the security area we do want, uh we do want to involve the academic community and to perform formal verification and analysis of the protocol that we are standardizing.

E

uh To that end, we had uh we had a presentation during the summer itf uh on thermal uh formal verification of ad hoc uh of an earlier version of ad hoc, using the summary tool in the symbolic model, which means essentially that the crypto or crypto is abstracted and uh seen as a black box and then uh the the the protocol.

E

Several issues found there and I think we resolved most of those uh one of the out of direct outputs of this analysis is that we added message for optional message for uh authors.

E

Please please correct me if I'm wrong uh in order to confirm for portico's explicit key confirmation in the absence of uh implicit confirmation through application tax, uh continuing the discussion, uh I was thinking what would be the best next steps, and we discussed this with castiga, who is leading the prosecco team within india, in france, who specializes in formal verification of protocols and implementation, and uh we have uh captic and his team- have ongoing plans on uh performing uh an analysis of ad hoc using the computational model and the crypto very tool, which would essentially give us uh uh probability bounds uh for different kinds of attacks and as a function of the different uh crypto modules that are used, crypts, algorithms, that are used and their probabilities and their corresponding probabilities.

E

uh So this is something that kartik and his team plan on working on kartik. Please fill me in if uh I'm taking something or if I haven't been complete, uh but then also apart from the protocol itself, we do want to uh ensure that the implementation that uh we produce and that we test as part of or as part of the interrupt testing event are also secure and what that means is uh in to this end.

E

What we in india did is that we are trying to uh formally verify the c implementation using the f-star language, uh which is an output of the uh prosecuting machinery again in order to study different security properties of the implementation, such as memory safety, uh functional correctness, etc.

E

So to this end, in the next couple of months, we will be working with kartik's team uh on uh modularizing our code, uh the implementation of ad hoc within the open wsn project, in order to make it ready for the uh crypto verification using f-star and at the end of this process we hope to have a formally verified implementation.

E

So those would be the two main points that we have. We still don't have a clear timeline, but we hope to have a better visibility over this for the next itf meeting and to present this to the working group. So if there are any comments, please please shout.

F

F

A

So I'll go ahead, I'm not sure who else was talking there. Sorry, um you so you're. Looking at a verification of an implementation whose implementation is that sorry, I wasn't clear. So that's what that is. Timothy's implementation.

B

A

Open wsn project, and just from my understanding, is that that's not that's nothing to do with india as an implementer you're, only being a tester in that role. So this is indriya's implementation that timothy is leading okay. So it's a it's an in-house implementation and test great okay, thanks yeah. Somebody else wanted to talk again. If you want to use the mic line to feel free, if we don't need it, if there's only one or two people.

G

I'll just do a small clarification on on the goals of this point, two here uh at least from my viewpoints, and maybe people can respond to that as well. I think what would be nice- and I think that we all agree in the working group more or less, but it's worth stating this out clearly is at the end of the process.

G

We have multiple proofs in different models that are complementary and that kind of exercise all the corners of the spec. So currently we have the the nice tamarind model, which is a comprehensive, symbolic analysis.

G

So the idea is to complement it in two different directions want to have a computational cryptographic proof using cryptograph, and the third one is to do an analysis of a reference implementation, so to speak of of ad hoc, so that you're sure that you're not in these models, because the models typically leave out certain details, because otherwise the proofs would never be possible, but when you're analyzing an implementation, you're sure that, especially if it interrupts that you show that it captures all the details, you then close.

G

The final problems that might come up in the state machine implementation or packet, formatting and stuff like that which should be ignored in both tamarind and cryptograph. You still have to verify things about it and that's what you verify in the reference implementation.

G

So that's the basic idea between these two different projects that malisha just described and I'm sure there are if we could get interest from other groups, there would be more things to do as well. But these are, I think, within these three, you would have a pretty nice coverage of all the specs. Anyway, that's my two cents and please ask questions and comments.

F

uh Cortex, could you um please repeat which, uh which um verifications you are doing? The tamarind was one, uh it's just for note. Keeping.

D

No tamara just.

F

D

Can adjust to that so.

F

D

Tamarind modeling was done by a team from university of copenhagen, uh kth and ericsson, and that um that there was there is a pre-print available, uh an archive and uh they have I talked to the author and they have essentially rewritten the paper with an extended analysis and that's been sent to a conference. It's been submitted and they wait for a response for that, probably in march sometime, so that's the status of and that they actually managed to cover some of the cases which they didn't cover in the pre-print. So it's it's fairly comprehensible.

D

D

Sorry go ahead, kartik.

G

uh No that I didn't have much else to add to that the uh uh so the tamarind analysis. Yes, as one says, it has already been done or is in the process of publication, but it's done uh by a different group. We are proposing to do a computational cryptographic proof using crypto verif, which is a tool which I can send a link around to later. Fdp on ether pad and the verified implementation will be done using f star, which is a third tool which focuses on verifying code or interoperable reference code in c.

G

So there would then be these three different proofs or three different tools which hopefully gives sufficient coverage on all the design elements of it. Okay, thanks.

H

I think there's great news earlier review by cfrd and academia had have led to a lot of smaller changes. Also, a lot of clarifications and eukaryotic has already heavily influenced the focus on forward security.

H

So we're really looking forward to this.

G

That's great so there's one question that still comes up when we are doing this kind of analysis, which is um uh in terms of what is I mean? Is there a documented target security level for ad hoc? Like I mean if, for example, uh we if you wanted to say that okay cipher suit 0 should provide 128 bit, security 2 should provide 80 bit security and so on.

G

Then there is something to also check during a computational analysis, which is because that you can actually check the concrete security bonds and make sure that each of these cypher suits meets its desired security level and currently looks like uh I don't know what exactly the current understanding for. I guess this also is inherited a bit from oscore because we use short tags and so on. So there must be some target security level that we are aiming for.

G

For tls, it's 128 usually is what most of the cypher suits aim for, but if there is a specific discussion that has already been happened, it will be nice to know so that we can make sure we conform to that discussion.

H

I don't think we have had any such discussion, not as written down, at least concretely, I think for in general, it's, I think, 128-bit security level for confidentiality, hopefully but 64- for integrity, which might also affect confidentiality, of course, for active attackers. um Okay,.

G

Maybe at some point it'll be worth starting a thread on the mailing list just to get consensus on these.

H

Yeah but then it's definitely different per cypher, so some of these episodes have longer tags and the newly added cypher suits aiming for higher than 128-bit security, complying with cnsa yeah.

A

So on that karthik, I I think it's a good idea to create a thread on the list. With that discussion, it would seem to me that there's nothing special, particularly about lake. In that that's, you know if we do reach consensus in the working group on let's say 128 for confidentiality and 64 for integrity, it's probably worthwhile bringing that up on the security area list in the itf, because presumably the same thing will apply in other working groups that are concerned about constrained devices.

G

Indeed, for constraint devices yeah, I think that's the the tag size, which is the only place where we seem to make some compromise here and so figuring out. What the impact of that is would be.

A

Yeah yeah, no, I mean, I think you know, I think, having a common security target at that level across multiple working groups is probably a worthwhile thing to do.

G

A

Okay, um any religion.

E

No, I I think we can go ahead, so this was just essentially a heads up for the working group on the funds that we have in this domain.

A

Great stuff: okay, uh do you want me to present slides for the next one, or do you want to take over.

H

uh Please present.

A

Happy to do that yeah, um so if it helps I can um at any point I can kind of pop up the issue tracker. If you want me to do that, just say: okay,.

H

A

Thank you off you go just. I went to the slide.

H

Yep, so this is presenting the changes and close and open issues in version zero. Four, we submitted version zero four uh yesterday and take next slide.

H

uh So main changes is that we are uh based on developer feedback. We are more or less going back to the solution in zero two, but completely changing this. The description of it. We it raised concerns that we were associated with the source cipher. Now we described it it as we using hkdf expand as an ad binary additive stream cipher.

H

According to our understanding, this provides better confidentiality than asctr, which actually is, is a permutation that don't really do well, uh but I have more details slide on this later, so we have specified message four as option to support as discussed so far. We have not specified any signaling instead making key confirmation mandatory, then the cypher suitable has been discussed for long term. Now we have implemented the suggestion from stephen from last meeting that one and two should be implemented by more non-constrained and more constrained devices should implement one of them.

H

Then there is new added text on error messages, and there has been a rewriting and restriction of section 1 to adopt the changes that has been make it better. Next slide.

H

So this is the open issues and I don't know, do you want to say something about them, you're on or the rest, we can uh no, no just.

D

H

Yeah then move next slide. I think so. Here's closed issues, uh so we don't specify airdoc as a cam. It didn't work out really.

H

Then we have sold. Hopefully the services issues uh psk this the name is psk each, but the issue is really lightweight forward secrecy that has now been implemented in the ad hoc re-key fs function. I think this will need more work later and interaction with core uh no resumption shaken kmac is done. Cyphysis with high security is done and we have added a reference to the co-cc board certificate work. We have got done several requests to provide test vectors for seaboard certificates and also for their encoded certificates, which will come later.

D

Sorry can I just interrupt for a second renee, please, on the previous slide. um I saw that apparently, so what is instead of fishing 512 versus.

H

256. of uh sha 256, it's the same as before. No changes.

D

Really discussion in december that 512 would uh not really be supported right by most advisors, so how? How are we going to get to interoperability? If uh what are we doing now? What's the, what is the normative text I couldn't find it.

H

The new normative it's in zero. Four, I don't know it says that you should once episode is as before, eddisa it's it's basically. Half of the comments were gotten is that ed dsa is the way to go people like that they can use threshold and they have no problem implementing it. The other half is saying we can only support chart 256 with ecdsa, so there is no changes to the cypher suits. The normative text is that you should support both, but if you cannot, you can choose one.

D

What, if xiao language, instead of shoot.

H

D

Yeah rene, please please, uh okay, so that too or stephen, if you could flip back two slides or three um there. Thank you so bullet three, that's the normative text and the reason for should, instead of shall was that uh there was an input from michael richardson last meeting that if we really want to nail down all the um the mandatory to implement uh not only related to cipher, suites and and then we should make it in a separate draft, and this draft should only contain the recommendation yeah.

D

So I said list I, as you probably recall, I had a presentation at the december 18 interim right and at the time and as I looked up in the minutes, it was also suggested to uh to support that which I have not seen before before the raffle yet. But I sent an email to the list about uh the best current practice about mandatory to implement algorithms, and I think that would be good guidance for uh getting to conclusion on that right.

D

E

Yes, I remember the email this was just before the holidays. If I recall correctly so essentially, you are. You are not happy with the current phrasing I mean uh of having two algorithms uh proposed and which should uh implement both of them. If the device is less constrained, am I hearing.

D

I think if, if you're you're going standard strike right so and then uh I think it should uh foster interoperability of devices and also use implementations that uh uh patients that foster interoperability in a low cost way right.

D

So what is your proposal? Rene proposal is to uh support uh sha 256, which is supported by most hardware, as at least as I know, as far as I know, and uh not go for a scythe suit, zero and two, because uh there's essentially a zero and four f, five twelve, which is not supported by lots of devices. I just checked it on a new github web page as well right so but john uh mentioned that we have a problem with the the community.

D

Some of split time in two parts where one part is, is targeting eddsa only and the other part is targeting ecdsa only, and how do we solve that yeah? So I I might have is that I have not seen any discussion since december 18 on this particular topic and now suddenly it's it's marked as closed where it bears.

H

Embarrassing working group.

D

Feedback on that right.

H

I think we had the discussion last time. This was.

D

Just marked by michael richardson, but uh that's not necessarily a working consensus.

A

So so that the shares didn't declare working or ask for or declare working group consensus on this specific point.

A

um So it's I don't think it's closed, um but I I think probably the best thing is: if uh renee, if you want to sort of refresh that thread on the mailing list, um and then we can, we can have a consensus on what we're either.

H

In github, there is where all the basically most of the discussion is where all the people developing or commenting.

D

We could we could reopen the implement the mandatory shot, 12 issue, but maybe it's better if you formulate your in your own words renee. Yes,.

A

Yeah, I think this is probably also one to bring to the list. um I mean probably an incredible mind, but I think in this case there's yeah. There may be people who are on the mailing list who are not active in github who have an opinion here. So let's do this one on the.

D

List, thank you.

E

Okay, so let's then move on. We have 20 minutes 23 minutes left in the meeting, so I propose uh we move on with the with the issues.

E

H

So here is encryption of message: two based on developer feedback. So basically we have the current zero four is more or less reverting back to zero. Two technically it's the same solution, but the label is different. It's key stream instead of k and the description of how it works is quite different, but technically it's the same same the candidate.

H

The other two solution has been not been favored by implementations. It's they see it as complicated, so and 01 was not dropped because it's insecure it was dropped because at least the description of it raised comments. uh I think the developers are happy with this current solution. As far as we have seen, and that is to use hkdf expand as a binary address stream cipher that fulfills all the requirements that I can see.

H

Next slide going through this fast as well short of time. So, if you have any comments shout out- and we take time to discuss that topic- then optional message. Four. This was raised by suggested by carl who did a formal verification this at kitteh, together with it university of copenhagen.

H

um This message is very simple: it basically only contains a mac and then a correlation identifier, it's optional to to implement an optional to use it's basically, the current id in ad hoc is that you rely on application protocol to get key confirmation to the responder and correct me if I'm wrong, but I think that's the idea in tls 1.3 also.

H

It was pointed out that carl, that not all uh all app users might use an application protocol at all, and now we have added a error message for that basically replaces sending an application that your protocol like or score, and you can use that if you use authentication only or maybe if you use only one-way application protocol, it was discussed earlier that this should be some signaling. That could then be in message one or message three.

H

After thinking about it. Our suggestion would be to not add any signaling. We think this is kind of a small use case and instead we would like to make key confirmation mandatory. So if the initiator is not sending any application data, they are required to send edok message for.

H

I think this would need to be implemented and hopefully some more comments in the future, but that's the high level plan currently.

H

uh Just a comment: yeah next slide, then uh issue is sure there. All the other messages have accelerated. Data should be accelerated. Data in message. Four and yeah open question adds complexity, but only for message. Four, which is optional, makes it look like the other messages, but so far nobody has expressed that they need this either.

H

So this will stay open for a while. I guess and receive comments any.

D

Comments now any comments now from anyone in this.

F

Meeting: okay, thanks.

H

Next forward backward secrecy: this is the we have changed. The name of this update function. Basically, it's a function, re-keying the key used in the exporter. This is a very lightweight way to get them forward. Secrecy and this work is heavily influenced by the earlier comments by celtic.

H

This relies a lot on core where oscore would have to is the main application protocol that would ask ad hoc for forward secrecy, so I think I think the main building places and ideas are now in place, but the details would come later when core starts working more on.

B

H

Excite so error message: diagnostics. It was comments that both a little bit unclear how error messages worked and how to distinguish error messages from non-error messages.

H

So we have added quite a lot of text to the specification after dialogue with implementers.

H

The idea is that error message is can is distinguish, as it contains a text string which none of the other messages do. We also change the name of this text, string from error message to diagnostic message.

H

Then we have clarified that the intention that all error messages are fatal. They close down the the the protocol, but also that they are not authenticated. So if you send them, you know this is fatal. If you receive them, you you, it might be an attacker something. You should consider that then. The other thing is that the basically there, when suit r suits, are included. It's meant for the ad hoc application.

H

When you use this text string uh and if suits, are not included, then it's a diagnostic mestic meant for human readable. It should be logged mainly used for some engineer. Debugging we have a now. We have a mandatory that this needs to be a basically a debugging error in english uh has further been.

H

I think this this fulfills all the requirements that the developer opening this issue had also been further discussion, whether the diagnosis messages would need to be standardized, could have standardized text strings or you could have standardized codes, but there has not been a clear requirement on that. Yet that's still up for discussion. I think the the text would still need some more guidance on when to send the error message, but basically the idea is if anything goes wrong. It's fatal and you send an error message.

I

So the question really is: um do you have to act on these things? So, given that that you already closed down the the connection, the the implementation does not have to act on this? All diagnostics are the same from the point of view of the implementation.

I

um The question is: is there going to be a human who looks at these diagnostics and and does different things based on different values of these messages, and is not a software engineer that that is actually debugging the thing right now, but does does that ever come up in operational context, and if you have an operational context where it's important to actually distinguish different kinds of diagnostics uh like the the key is expired or whatever kinds of specific diagnostics that that an operational person might want to act on.

I

Oh, I I have to renew some certificate or whatever. um Then it's actually that then it actually may be useful to to standardize, uh not necessarily diagnostic messages, but at least categories of diagnostic uh messengers, so that the user interface can give you a chinese message.

I

The the keys expired get a new one or whatever these diagnostics would tell an operational person.

H

Yep could make sense. I guess you that's a suggestion from you. I think we would need to. I think that would be quite easy, adding an integer or some prefix of the texturing or something and categorize that I assume looking at tls1.3, would.

H

Help um could be a good guidance for what kind of messages could be concerned.

I

So, maybe that that's a good thing to actually throw over the fence to iot, ops and and ask them what what kind of operational information do you want out of these error messages.

D

Good good idea karsten, so how do we do that? Is that an email to iot ops or is it.

A

D

A

I think it's an email yeah so does somebody want a volunteer to send that mail.

D

I can send it right. Thank you.

H

H

Then there is um additional issue related, but asking. How can we distinguish between other messages, and this was first from marco and then there was another developer. Also commenting on the same thing, I think it was peter.

H

I think this needs some more consideration. I think the initial idea of ad hoc was that you would not use that that this would be sold by the lower layers, but and I'm not sure if there's something missing or if the implementation thoughts in addock is not aligning with how people would like to implement this. I think this needs to be analyzed and considered further, and maybe there will need some addition to the messages or guidance how to distinguish them.

A

So, just as a time check we're 10 minutes from the end, I guess we have about six slides left. um I I think probably perhaps the best thing to do is if people are okay running over five or ten minutes. Try and get to the end is that okay.

H

A

uh Okay, so let's proceed yeah.

H

Next uh so length values when using an exporter. This was open uh one two weeks ago by marco. So yes, right now, when using ad hoc, the lengths of the key and the salt you export are fixed. The length of the key is the key length of the aad used, but all score is deriving keys from this master key, so this could potentially be longer and then the master salt is set to eight bytes. This could potentially be shorter if you have a longer key or longer.

H

If you more want more randomness, it was compromising a trade-off and marquis is suggesting that these number are made defaults instead of being required and that an application two parties can agree on other things, and this would this would this would definitely work would maybe somewhat lower. Interoperability would add flexibility.

H

um I don't don't know if you want to say anything on why you want this.

J

Yeah just to clarify, I think they are good default values by the way, but there are chances they can get them through other protocols, for instance, a possible uh edo oriented profile base with an authorization server mediating and knowing the preferred values uh for the for the responder, essentially at its registration time and then synchronizing uh the initiator later on during the ace workflow as an example. But there can be many.

J

H

Any comments anybody positive to doing this or negative. I.

H

Think it makes sense if there are use cases that want to do that.

H

Okay next slide, please please discuss all these things on on the list or on github. There are issues for everything there, then passing information to application is an issues. The the current document says that if there is error, you should not pass everything to the application, but, of course, in the case of an.

H

Error uh in the case of an error, you probably want to send basically the whole message stream as a debug message for locking diagnostic.

H

So I think here the documentation need to be.

H

H

Not really as a ordinary error message as it should be locked which not forbid you know to to load this information for the banking yeah. Next, some more ways here there was has been several requests to add real certificates, um uh for example, both cbo certificates and experience, 509 they're encoded.

H

We added now reference to the seabor certificates. They are basically similar as the x 509 and then using a kid to identify a certificate has also been discussed in cosi. We should align with that.

H

I think there are quite a lot of certificate rule public key issues that we need to bring up for discussion at the at the next itef.

H

But so far this is just a very simple addition similar to x539. You can also now we have examples of using civil certificates. Next.

H

Test factors is: you want to go through this francesca?

H

I think she she's left for another meeting. Okay,.

D

How are you here, yeah.

C

But yeah these were the um additions that were done to, or that came from feedbacks from the interrupt, both the first and the second one, and um we have started doing some of this. For example, we obsoleted the test vectors and we started the adding the th4 output and export and export exporter outputs to the test vectors. But to to do the rest of this, we um we have to like regenerate new test vectors and change the values.

C

um Probably we need to check the code, but um we haven't done so because we want to continue the in the prop based on the same test, vectors.

C

Yeah and then other additions will be um adding c board certificates and possibly later asn one or their certificate encoded certificates and then uh more cypher suites.

C

I don't know if uran or john, you want to see anything more about that.

H

I think that was a good summary, so unless there's any questions, we can take next slide.

H

Recent issue: um yeah, there's a question recently open issue: question: why um why we restrict the number of parameters in the cosy key discussed it shortly? This is not strictly necessary, I think, but on the other hand, if we allow all parameters we need, they need to.

H

The parties need to agree on not only the content but also the ordering, so that would be need to be specified, and I think this is a non go will be an ongoing discussion on github.

H

Then there is change message, one format, and this is related to the distinguish between different messages, but here's a concrete suggestion from peter that we should have a connection identifier, also in message. One.

H

And yeah these have not been discussed. This was recently very recently open. So I don't have so much comments, um except that there are newly opened issues next slide. Unless anybody have comments.

D

Okay, so summary, just adding one word here is that the uh I mean we are going back now somehow to to things that are looks very much like version zero, two of the draft, so it should be, and the changes we make are only changes that will will impact test vectors. But it's so we haven't really changed the the actual protocol in the in the large in the long time now, which I think is good but uh yeah more more issues pop up and we try to try to resolve them.

D

But the main discussion has been on on github, so if people have only followed the the email is, then that that wouldn't have given the fair view of what has actually been happening. So I encourage people to look at uh issues, but we can also bring things to the mailing list, as as people like.

A

A

Great thanks and yes, I mean, I think you know I've encouraged people to discuss things on github. uh I mean obviously clearly think that you know finally evaluating working with consensus is something that will happen based on drafts on the list, but uh and for example, with the cypher suite uh shoulds and muslims are we we might wanna we'll try and get that pinned down on the list soon. Okay, uh any other issues on these ad hoc status and issues are with fat. Four.

A

Not hearing any.

A

um So, michael is saying: we need the github to mail in the summary configured. It is I I guess it is configured. um I believe I see those mails on sunday mornings can somebody else confirm that.

K

Then it must be obvious that the github activity is seen by the mailing list. Despite what euron just said.

A

Yeah, so I I did the github issue. Mail goes to this. um I believe everybody's seeing it, but if not, that would be good to know know if it's enough to be particularly useful.

B

E

That's not the end, all right, maybe you're, referring to the holiday period when there was no activity on github that I think two weeks fast without an email generated by the script. But I think the the digest is generated properly. Whenever there is activity.

D

Yes, what I was referring to that the actual discussion takes place there, the actual comments from the from the implementers and from from others take place there. So we haven't had any real discussion on on the on the mailing lists, but.

A

So I mean that there has been still but not huge. I mean it's been over the holiday period discussion in github.

A

There is a weekly mail generator that I think I'm displaying one on the screen there from uh last sunday uh as malaysia says, if there's no change on github, there's no mail and- and I personally don't find that mail particularly informative.

A

Nor do I find the notifications if you're subscribed, so you it takes a bit of work um and I don't michael. I guess I don't think, there's a need for the editors at this point to kind of create a mail thread for each issue. They think is nearing resolution.

A

um Maybe we might get to that later, but just with the, um I think, with the you know, issuing drafts that the interoperability is on. I think we're doing. Okay, for now, um with the exception of that issue, renee raised, which we will bring to the list, um is that okay for everyone.

A

Yep great okay and we're trying to finish in a couple of minutes. The other thing we had on the uh agenda was itf-110 again. I think this might be almost a no-up. I had two questions. One is um whether the people implementing um are okay to kind of coordinate with these all the changes that they expect between now and the next time they do it a hackathon event or something around itf-110 or if they need the working group to have kind of a draft five produced that they'll implement too.

A

So, in other words, do we either draft five or six? Whatever happens to be so that the implementers can know what to code to before the next in drop event or are the implementers okay? Without that.

J

uh Marco, here I'll try to catch up with the latest version published already it'd, be good to have heads up on further big things that can come up on top of them.

A

Sorry, marco, just just I wasn't entirely career of the the the upshot there. Can you be specific? Do you need a new, a version five or six or whatever, before itf-110, to implement two, or are you okay, with keeping up with the latest in github?

A

I am yeah you're, okay, with keeping up the nice thing about it, okay and any other thoughts on that, and if the answer is everybody's okay, with keeping up with the github thing, then that's fine.

D

So I think just adding from from the interrupt uh people had implemented version two, and uh I mean the natural step now- is actually to move to version four, because because this uh yeah, as we've talked about it's, it's basically aligning with version four. uh So that would be the next step.

D

So I think that version four is a natural upgrade if people have the time or otherwise we interrupt with version two, those who still have that version which, which has been the same for six months before that, so so that that's what people have generally.

A

Great, that's! Okay! If the implementers are all fine with that, that's great um just wanted to check, and then second thing I had for icf110 is: have we got any specific goals or issues that we'd like to try and close off? uh We don't need the answer right now. We can do that on the mailing list, um but just yeah.

A

What are our goals for itf-110, uh any specific things people want to bring up now to say we really should sort this one out in that time frame or is it okay to just keep as we've been doing and letting the editors figure out which of the issues that are worth trying to pin down.

A

I'm kind of hearing nothing, so that's, let's go so I think that that says uh for itf-110 we'll proceed as as in this meeting and previously we'll let the editors say: here's the list of issues and here's the ones we want to try and talk about, pin now.

D

Yep sounds good.

A

Okay, that's all I had sorry for dragging you over six minutes late uh militia. Anything else from you. Oh no, not really, but is there any other business.

A

I hear none, so I guess we can close the meeting great thanks all for taking part and we'll talk to you in the sometime in what normally would be an itf meeting. Yes, sounds good talk to you later. Bye-Bye thanks.

E