Internet Engineering Task Force 109, 16 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF109-SECDISPATCH-20201116-0900

Description

SECDISPATCH meeting session at IETF109
2020/11/16 0900

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

A

A

It's started slowly.

B

Okay is it is anything working here? Firefox is asking me: okay,.

A

I can't see your screen yet, but.

B

Okay, give me one second here: this is the fight.

A

We got you here as well.

C

Yes, can you hear me.

A

Yes, we can hear you.

C

Should I be prepared to share my screen.

A

If it's, if it works for you, otherwise I can drive the slides. It's fine.

C

I can just check, um should I check it right now.

C

See which one yeah, but um can I choose yes, I can choose, I can choose, share screen too. Okay.

D

C

Yeah, that's great good and I can stop sharing there great.

A

That works then.

C

A

B

Francesca, I think you might have to drive my slides. uh I don't wanna okay, we start firefox right now.

A

Sure I'll prepare them.

B

A

A

A

But I'm sure that's.

A

E

Yeah, I agree with your assessment of the time. I think we can probably go ahead and get.

A

A

Patch working group thomas feel free to mute yourself and and stop the video as well. If you want.

A

This is an itf meeting, so the note well applies, please um take some time to read and understand what is written here if it's your first session and reach out to us, if you have any questions.

A

This is a slide about this ipf 109 online meeting tip just as a warning. This session is being recorded, make sure your video is off unless you.

A

A

But if not, it doesn't matter by now, the blue sheet are automatically generated. So no need to worry about that.

A

Yes, we have a chat that is synced with jabber, so you should be able to use either one of those and we will be monitoring the chat and for more information and assistance. There are two links that are useful and, yes, let's move on some more links which are um specific to the session. We have our mythical jabber uh the minutes. Thank you to our minute taker, but anybody please help out, especially if you have a comment. The microphone just go to the minutes and check that it was correctly captured.

A

We have the link to the slides. There is our emails. I am francesca bini co-sharing with kathleen and richard here, our list, our charter and a link, our wiki.

A

Be quite we have quite some time today we have this. uh We are now in the intro part of this presentation and um uh after that thomas will present interoperability architecture for blockchain gateways. uh He has 30 minutes and then dane from iot security shaman. I hope I'm saying your name correctly for 30 minutes, and these are the two items that we need to dispatch today.

A

Then we have the signature, validation. Token svt, update stefan- and I just want to remind that. This is not a topic to actually dispatch. This was dispatch at atf 107, but since this was since we had time today and this uh we requested some time um this was requesting some time we added it to the agenda um yeah. I see that stefan is in the queue so go ahead. Stephan.

C

Sorry, I I completely misunderstood that uh intention. Tension for participating with this presentation today was that it should be dispatched today, because what we did last time was make a presentation, but we never dispatched it. We decided to create a a email list that we never created. So this is the time where I would expect this item to be dispatched.

A

We did discuss it and dispatched it in an appropriate way, which was create a main list to get to see if there was interest to move it in forward.

A

And, according to the charter, um once items are dispatched, they should not be brought back. Obviously, unless there is some substantial changes.

C

um Which I think there is so could we could we at least have the discussion and then decide whether we want to dispatch it.

F

So this is kathleen, um the list being not being created, was probably a backlog item, so I'm assuming perhaps it just didn't, get done for administrative reasons, not for any purpose. So we do plan to have the discussion but, as francesca said, it was dispatched. um So let's make sure a list does get created this time. So stefan will need your help on that and then the ads as well.

C

Might be to put this actually in a working group because we think it fits there and then it would be unnecessary to create a a a list, because it would be better to discuss it in the working group where it could be dispatched. Or is it completely impossible to add a working item to a working group if it has ever been discussed in the second dispatch.

A

C

Not then impossible.

A

But let's let's hear from our ad ben: go ahead: yeah.

D

I mean the the short summary here is that, yes, we did attempt to dispatch it to an emailing list and the list didn't get created and that's just because the 80s didn't follow up and we didn't get a reminder about it. So, uh in order to create a list, we need a few pieces of information.

D

Some of those we can't actually guess ourselves. So stefan, if you could please follow up with us after the session, we can get you the list of pieces of information that we need to create the list. There's no problem, creating a list and then later wanting to create a working group. We can reuse the same list if that is appropriate.

D

So I think the best path is to get the list and then, um if we have interest- and we want to turn it into working group, we can proceed using that list as well.

C

We can take.

D

G

C

The idea was not to create a new working group but to fit it into one of the existing working groups. Oh I misheard yours.

D

C

It would be unnecessary to create a mailing, because that was my only point. I see we can talk it later. Take it later.

A

Okay but uh yeah: let's take it later and continue this discussion during the time slot we'll have time anyway, um yeah 25, minutes, open mic and then conclusion by the chairs uh so release patch process. This is just a reminder for everybody that the sect dispatch recommends the next steps for new work.

A

It does not adopt drafts or does the technical work in the working group so possible outcomes of this patch of this session today will be to direct the document to an existing working group propose a new, focused working group ad sponsorship, assuming ada is willing additional discussion or community development is required and itf should not work on this topic. Those are all valid, dispatching and just to to uh underline uh or to to go back one second to to the previous document.

A

um I I think that the dispatching uh outcome last time this document was discussed was an additional discussion. Community development was required, um but let's take it later, so we can move on.

A

So um just a quick run through the the uh participation guidelines when you're at the microphone. Please state your name before speaking. If you can remember, it helps with the minutes taking and also for the recording and keep the dispatch question in mind. So it's great to have comments and feedback about content, but please try to keep it constructive and also give advice on where you think this work should go if it should go anywhere and keep your comments, quick.

A

If you can two three minutes, we have more times today, so we're less strict about that uh to speak.

A

You'll have to join the queue, which is the hand icon and then once you're given the floor, you can send audio and video if you want, and then there is other controls such as show hand which I'm not sure we will use today and the chat which is synced with jabber. As I said, and yes, one slide for show of hand, but we can move on to the first topic to dispatch, which is thomas.

A

So please you guys hear me yes, so let me just.

B

Okay, thank you francesca.

B

A

So so just get.

B

A

B

Okay, sure sure so I just want to say thank you to the sec dispatch chairs and also to the ads for the opportunity. I think the goal of this presentation is just to make uh folks aware of this. um You know ongoing effort and to invite people to to participate. So so this is just the the outline um of the presentation.

B

um I prefer to finish the whole thing so that everybody knows what's in scope and what what is our scope, and then uh you know if you, if anyone has any specific questions about any specific slide, you can always go back and and the slides are posted. So so you guys can actually, you know read ahead of me. If you have uh you know, questions uh next slide, please francesca.

B

So so, what's the what's the problem statement you know for uh folks who are following the whole, you know uh blockchain uh dlt, discussion, narrative uh and for folks who are following the discussion about you know: decentralized, finance and d5. It's it's very clear that that um you know um the industry is still in the nascent state. We have very poor interoperability between a systems and um right now, if you want to do um you know, asset transfers, virtual asset and I'm using the word sort of generically.

B

You typically have to ask uh help from a third party entity which is in the industry typically called you know, crypto exchanges and in the united states there's about. I don't know between 25 to 30 crypto exchanges. Some of them are well known, you know uh kraken um a base and so on, and so the the problem there is, in fact the the crypto exchanges themselves become. A centralization point becomes a choke uh point and it in fact goes. It goes against the whole um sort of ethos of this.

B

This decentralization and autonomy right, if, if you're dependent on a third party to do anything outside your system. Well, you know you're kind of you're kind of um you know constrained you're, not really you know autonomous and in some cases it could lead to asset lockets. So for those who uh paid attention to the cryptokitties incident, it pretty much. You know, put ethereum.

E

B

At a halt, which means, if, if you had assets there that have nothing to do with with cryptokitty and you're trying to exchange it you, you know you're you're impacted. You know by that um next slide, please francesca.

B

So this is a quick, quick diagram for those. You know we don't know you know I I like to use visuals, you know being an engineer, so this is kind of what it looks like there's an exchange entity in in the middle um next slide. Please uh franciscan.

B

And so what we think we need is a specific model between two dlt systems based on on gateways. So we need, you know, standardized protocol.

B

The protocol needs to be agnostic to the economic value and and right now, if you read a lot of the literature, there is a lot of confusion between you know the notion of economic value and in fact some people are now even questioning you know what is economic value like you know, uh and so these gateways uh stand in front of their uh dlt system. Each dlp may have multiple gateways.

B

So these these questions that we need to answer, such as you know, how do you pair up a gateway? How does a dlt system elect or select a given gateway? You know to talk to another gateway and I just noticed: there's a typo there. uh The second gateway should read up g2, not not both g1, so it's g1 and g2. My my apologies uh next slide. Please please francesca so so this is kind of what we are looking at the model here is that you have gateway g1 and g2.

B

um There is the protocol in the middle. We call it generically the gateway protocol, but we actually have a draft that the uh open digital asset uh protocol or odap- um and this is uh this- is draft hargraves. You know dash odap, if you just uh google that and um the the model assumes that on both sides there are resources instead of talking about blockchains or dlps. We just talk about resources. There are interior resources to a dlt system and there are exterior resources.

B

The interior resources, uh whatever the dlp is using, it could be its own ledger. It could be the public keys, uh it could be. You know, consensus protocol if you want to call that a resource, uh and there are things outside any dlt which are off chain resources. What we've been calling exterior resources- and those are things like um you- know- asset depositories that can actually perform validation of the true nature of an asset.

B

So one of one of the problems today is that there's no definitive, um you know entity authority that says well, okay, this this is a stable coin. That's coming out of this group, so so so you know, even even in if you guys are following the whole libra thing: libra version two, which is actually a stable coin, question becomes: uh what is the legal status of the organization when they they proclaim that this is a stable coin com coming out of liberal right, so that that's kind of out of scope.

B

But but let's say, for example, in this discussion, you know the client wants to. You know affect the transfer across g1 and g2. Well, g2 and g1 need to understand that they're talking about about that very specific, you know uh asset and, and there's no there's. No, you know discrepancy right. So so we'll we'll talk about that later on. um uh But but this is this is the model, and the scope of work for the itf is: is that in the middle legs g1 and g2?

B

uh What what happens in between what? What does g1 and g2 need to have in terms of capabilities in order to perform a unidirectional transfer next slide? Please francesca.

B

So so this is, this is in a single long sentence. What is what is it that you want to develop? So so it's it's a gateway to gateway protocol that allows the secure transfer of a uh digital asset representation. So just put it that way we can we can. We can talk about. You know, what's the definition of a virtual asset, it's unidirectional, so we want to focus just on just a one-way unidirectional transfer and get that working, because I know there's a lot of interest in industry with a thing called atomic swaps.

B

If you guys know what that is, which is a this is a dependent. You know uh two two directional transfer um uh and there's some issues there. You know if you guys know what the hash lock and the time lock is and there's a lot of issues there. So you know what we want to do is just do one direction and make that a building block, because if you can get that working, you can do bi-directional with conditionals using the unit directional as a building block.

B

It needs to satisfy some requirements and that's in the architecture drive now. Basically, requirements relating to atomicity, you know the acid properties and the non-repudiation, meaning that, if anything happens, there's a crash or there's some kind of an attempt to cheat. Then both g1 and g2 have sufficient evidence for uh you know if they have to, um you know, argue, and they have to um you know dispute. You know the transaction. It needs to be agnostic to the higher level economic value. So so this is.

B

uh This is actually very much like the end-to-end principle, where you know the the as well, knowing being the itf. The the ip network is agnostic to whether or not the the datagram is um is a you know, a video, uh you know, part of video or part of you, know a voice or part of something else, and next slide, please franciscan.

B

So so, what's what what do we see as uh items in our work in scope of work? So we want to define the apis of both ends of the gateway so and right now we're focusing on wrestle apis, though, if we do this correctly, then you know somebody can you know if they want to implement it using you know a you know: uh state full um sort of messaging in a protocol.

B

You could do that as well, but but that's what we want to you know focus on today we're going to define the resource identifier so that g1 and g2 can be pointing to the the same things using the same identifiers.

B

uh We want to define the message, flows and, of course, the payloads that go into that that message and also a set of commands. You know that that some of the messages are, in fact you know uh you know affecting commands to between g1 and g2 um secure channel establishment. We we want to use whatever. Is you know available today? If it's you know jealous 1.3, you know great. um You know that we don't want to do anything new there.

B

We might extend the terminology of uh the nist, mr mr80202, which is actually a great document. If, if you want to, you know, point anybody to a sort of reference document about terminology, because there's so many there's so many so much confusion in terms of terminology in in this space, I would recommend looking at that nist document uh next slide. Please francesca.

B

So all this is out of scope, so we are not going to deal with blockchains and dlt systems they're, not going to propose anything anything new in blockchains and dlps we're not going to focus on consensus and vfd protocols. I know there's a lot of interest in proof of stake, proof of work uh and so on. uh We're not gonna do cryptocurrencies and tokenization, and I know some of you might be saying.

B

Oh just you know, if, if itf, we just issue its cryptocurrency, we can all be rich, but unfortunately we're not gonna do that in this effort. uh So we're not gonna talk about incentive mechanisms, zero knowledge protocols, another hot topic, um so authentication authorization we will use whatever has been standardized. So there are some cases where we think for say a private dlp system that, in order to access uh the the resources uh interior resources, in fact, also in fact the the exterior resources that the query needs to have some kind of authorization.

B

Well, if it uses you know, oauth or gnab great. Let's just use oauth we're not going to invent anything new there we're not going to do any concurrency control algorithms. uh If you look at the architecture, draft we're just taking uh the two-phase commit or three-phase commit as sort of the basis it's it's 30 years old, 35 years old um from jim gray, back in 78 79, it's well studied well known, implemented everywhere. If you have any kind of database in your organization, probably has to face commit identity management, so identity might be needed again.

B

That's out of scope for us and identity privacy. Data privacy is out of scope for us, and the list goes on. If you have any questions you know of whether or not something is in scope, you know just send it to the mailing list, and um you know somebody will answer or I can answer it. If no one answers next slide, please um francesca.

B

So so um some desirable features well, it must work if one or both of the dlps are private right. So this is one of the the key issues today. Is that that um we cannot assume that the world in the future will consist of one gigantic. You know permissionless public, uh blockchain um or dlp. It's that's not how the world works. In fact, there are already private dlt systems running today. If you just google, the jpmorgan, you know, coin jpmt coin you'll see that the the monetary authority of singapore is already running.

B

You know uh internal tests on on a private. You know blockchain dlp, so and and that's how it is the geopolitical issues right, so so for those who are following the the central bank issued currency. Cbdc's you'll understand that that that's a very complicated, geopolitically loaded issue, and so um you know uh you know we need we need to. We need to be ready for the case where the world has. You know private dlts.

B

It must work with one side as a legacy system. So, for example, if you look at g1 and g2, we have to be ready. We have to design it so that maybe behind g2 is not a dlp. It's a legacy system, it's just a monolithic. You know.

B

Computer system uh well, g1, really shouldn't care about that, and- and vice versa right, so that the the interior, the complexity of each of the dlts or systems behind the gateway really needs to be hidden away so that it doesn't, uh you know, uh influence the the design of the protocol it. It must result in atomic settlement with sufficient evidence. I've mentioned that before and it needs to support different client modes. So in the odap draft, you'll see there's three different modes and we think that pretty much covers.

B

You know most of the types of interaction between the client and and the gateway right, and so you know we can. We can discuss that. You know later on, if there's time or you know, if you have any questions about that, you know throw it on the mailing list and and and martin or myself or luke. uh You know uh we'll answer that um next uh slide. Please um francesca uh just the uh throw this out so that you know um people know what we're referring to.

B

When we say atomicity, so we want the acid properties to hold true when we do a unidirectional transfer, so that means in terms of of the actual asset. um If there's any failure, you know before the commit, then you know the transaction needs to commit or completely fail. So so that means in terms of uh the the effect on the asset. The asset must not change in terms of its ownership uh needs consistency. So so you know a transfer, you know must always result in the asset being in one dlt.

B

Only right so you can't have, you know, duplicates um isolation. While the transfer is occurring, you know you, you shouldn't be able to change the the assets. So so let me explain so if, if alice in you know, glt-1 is trying to send to bob in the lt2 while an analysis initiated transaction and a gateway is processing it. That asset needs to be made unavailable to alice, so that alice doesn't use it for another local transaction, effectively doing a double spend.

B

So in fact we want, we want the no double spend rule to hold um during an asset transfer uh durability. So this is a this is a big issue and, and we've had discussions on this um once once you reach the last stage of the two phase commit, which is the commit final. um You know, and and that means both sides- you and you two have agreed uh to commit.

B

uh If one of them crashes, then you know it, it needs to hold right that that that the the commitment is final, um and so this brings a whole lot of questions about what you know even before we reach that phase. What happens if, if one of the gateways crashes right so so this this entire question of gateway crashes, is a very important one, and you know we've got um you know, discussions going about that uh next slide. Please francesca.

B

uh So propose deliverable so so um uh so so.

B

Why am I watching intro? So that's not my slide.

A

No, let me just uh yeah.

B

I I I know that I know the ripple guys and I know I know in the intelligent project, um so so the deliverables. Let me just continue while francesca is talking, um so so uh I'm of the mind that I think a good working group has very specific deliverables, very well-defined, possibly narrow scope, and you know a well-defined. You know timeline. So so so our proposed deliverables are um architecture, specification, architecture, draft uh the protocol draft and the use cases rough, and we have that up on the data tracker. You know loaded optional.

B

Again, we don't want to over commit over promise. You know two additional possible work items would be an asset profile, json specification. So so it's basically you know given an asset profile, if you guys know who the dtcc is in new york, it's the it's the certificates depository. So if you you know, if you own, you know assets do whatever you know real estate in new york that she's a paper you may not want to hold it.

B

You know you deposit it in the safes of the dtcc and and they make a statement, but but uh in order for g1 and g2 to be able to refer and talk about the same asset, there needs to be a standard on like a json. You know representation of that asset, so it needs to have you know the issuer name. What's the asset code name? Is there any denomination? uh You know uh it's? It's literally.

B

I don't want to say an attribute certificate is, but it's pretty much an attribute certificate that has all the attributes of the asset. It's just a description of what it is. It doesn't say anything about ownership, status and so on and most important thing. It needs to have a validation, endpoint, a url there. That says this is the place where you can. You know validate the status of this. You know this asset, particularly legal status.

B

um The other one role is to uh crash recovery, so so uh in our model, g1 and g2 needs uh to maintain log. You know for every message it needs to block so so the question is what bits and information need to be kept by g1 and g2. Just in case one or both you know crashes. So that's you know. The first question second question is what what is? What is the recovery model? Do we use pairs? You know uh primary and backup gateways.

B

You know it's all the obvious question very interesting, but but we're going to put that in in in that second, this last bucket of the log metadata log data regarding in a crash and- and if there is in you know interest, then we can, you know, make that you know we can focus on on that draft um next slide. Please uh francisco uh so proposed roadmap, so we're here in itf, 109 uh doing the presentation- and you know we'd like to invite people to participate on the mailing list.

B

The mailing list is at the bottom of this slide. uh Our plans is to uh request uh for boss session uh at the next ietf in march, basically to ask for a working group. So so the aim is is basically to work on the drafts until it's reasonably mature.

B

That we understand more clearly what is in scope and out of scope, uh and we identify some of some difficulties. You know quite complex questions. um We'd like to you know, work on the three drafts. At least you know you know and get it finished by.

B

You know the november ietf next year uh and then then you know, if that's accomplished, we can say well, you know, do we close down the working group or do we recharter, meaning, you know add you know, add some more items, but basically the next sort of milestone for us is is asking the ads and and the security area for for a buff uh in in march.

B

um Next slide. Please francesca!

B

uh So I I I had uh this question actually several times from people like you know some people don't know who or what the itf is. uh Some people do and of course groups are like so why the idea? Why not go to these various organizations? And- and there are several and I won't name them and and go there- and my answer is that you know uh the itf has neutrality in this particular area, so the icf doesn't claim to own any specific. You know um blockchain or dlp system right, it's pretty neutral.

B

um More importantly, actually uh the itf has a long history of gateway protocols. But for those who are around you know back in the late 90s, you know ibmr ibr the whole discussion about you know bgp and for those who are in the uh ipsec uh working group in the late you know 90s, you know again, we had you know uh uh the ipsec and the ike discussion, and- and you know, if, if you think about it, a a vpn box, that's you know running ip second ike ip1 or ipv2.

B

It's essentially a gateway right, a gateway that that interconnects, you know subnets or networks, and in fact you know, enterprises. The security area has a lot of uh expertise in security protocols. um You just have to visit the rats working group and- and you know what I what I'm saying and you know so. I I feel comfortable that that we will receive sufficient.

B

You know, criticism and- and you know, positive contribution to the design, and I you know I prefer to be you know getting these difficult questions in the itf. You know, while the protocols are being developed versus you know later on. You know, you know down the road when you know we find you know flaws and for those who who um didn't know don't know about the itf, I usually say.

B

Well, you know, itf is the home of gcp ipsec I per brush tls oauth glab, you know all the json encryption and signing co-op rats and so on and the itf, as far as I know, has numerous uh liaison agreements with various organizations. I think these are the things. These are the liaisons that I'm aware of you know in the past, itu, 3gpp and so on.

B

Next slide, please.

B

Francesca, oh, so that's that's the uh this is the last slide uh cough. You know please join this. This mailing list you know uh do I do ask questions because uh we don't know uh of the answers and uh the the more questions uh we have, the more uh clarity I think we'll we'll get you know with regards to the design of the gateway protocol.

B

uh So that's the end of my slides. uh If anyone has any questions, uh should I turn off video francesca.

A

You can keep video on if you want, if you want okay, my queue for anybody who wants to want to give any feedback, and also there has been a lot of discussion in the chat so and we lost one of our co-chairs.

A

So let's try to keep the important comments to to the microphone so that we get the good feel of the.

H

Room, jonathan hoyland, um so if you wanted to get in here, that would have been fine with me, but um uh but I guess not um so uh thanks for the presentation, thomas, um you know, I think it's certainly fine for you to have a mailing list, um but um you know I'm somewhat familiar with this.

H

I'm somewhat familiar with uh the technology, though I'm proud as familiar as you and there's a bunch of concepts here that I think would be required to um I've seen this successfully that I do not think are familiar to the itf um and I have to say I look at your. I look at your current mailing list and it seems to have like relatively lot of participation from a lot of people. I would think would be relevant for such a protocol.

H

um The example um examples you gave of um the the signal difference between the examples you give your protocols uh that we do gateway protocols, and this is like we actually understood the protocols and largely controlled the protocols on either end of the gateways, and in this case we do not.

H

So I guess um you know we had a number of puzzles for um blockchain work in ietf and we've largely not done any of them, and I think that this one we also should not do um for basically the same reason, which is we don't know what we're doing, and um you know um I think, if you show up with like you, know, major representatives from like four different important blockchains, then my opinion will change but or it might change, but I think at the present. That is not the case.

B

Sure sure uh yeah no no agree. I think I think part of the sort of my approach in life is. If we don't understand it, then let's, let's work on it, so that we understand it right and but you're right.

B

I think I think our effort now is you know uh to get you know a number of the you know, participants and- and I know who you mean like this three or four- the of the of the sort of projects out there to get involved, because in fact um you know something like this benefits them right and so and also we're trying to get the the the user base of of the technology involved right.

B

So so you know um crypto exchanges, uh you know um crypto providers, you know to get involved in in this work, but no.

E

B

That's that's that's very good comment and all quite quite legitimate.

A

Thank you. Go ahead. West.

G

I think it's actually you. uh I was debating whether to ask this question. Then you just led with the information so now I want to ask the question which is: do you have any idea how large this solution would actually apply to in the real world?

G

I mean you know: are we talking just a few connections between a few uh various blockchains, or you know it's sort of an n squared type problem, because you you know in theory, you might have a connection for every particular blockchain and every other particular blockchain, but unless you have a lot of buy-in from existing people that want to do this, I worry that it could be a lot of work for uh not a whole lot of gain.

G

If, if you know it's not actually going to be used, it seems like we should get a lot of buy-in at the time. I.

B

Agree agree, that's a actually very, very good question. Thank you so so so, actually one of the reasons that motivated this work at this time, you know we could have done this five years ago. You know is, is a couple of things. um The fact that that you know bitcoin is now at least 10 years. Old ethereum is five years old. uh Six years uh we don't have any interoperability. Interoperability between the two. You know uh hyperledger fabric, with all its um sort of um different groups, it's at least four years old.

B

So we still don't have interoperability, but the big one is this question of you know central bank uh currencies so so for those who are following this, you know discussion, you know the sec, the fed, uh the u.s fed and in fact, even even the the ec eu ecb bank in europe they're all contemplating the need of a digital fiat currency. A digital currency issued by you know a sovereign government right, that's kind of the you know uh the definition. So the question is: will there be a role for blockchain and dlps?

B

Maybe maybe not there are some people saying? No, we don't. We don't need blockchains or dlps, that's fine. Some people are saying that actually we might need it, and so, in fact, uh I personally believe that interoperability will be forced upon all of us. You know the whole world if we really want to use um central bank issued currents cbdc's, so so without interoperability, cbdc's will not be able to flow across systems which is in fact again totally opposite than the whole idea of of of a fiat.

B

You know fiat currency, so so, if you have a greenback, you can go to any bank in the united states and that greenback represents your claim onto the issuer. In this case, the central bank and every bank will accept it well right now we don't have that so that sort of, if I come along with a particular stable coin, there's there's only a limited place where I can actually be. You know, exchanged or that my currency will be accepted. But no that's that's.

B

In fact, a very good point uh was, and you know that's that's one of the reasons why you want to have you know a mailing list is to get and invite all these people. Many of them are not itf people, itf attendees, you know to come and participate.

A

Okay, next, thank you. Daniel go ahead.

I

uh Hi there, daniel kahn, gilmore, aclu, uh so thomas thanks for this presentation, I'm still struggling a little bit with the um the underlying uh ideas, uh I'm in particular concerned that I don't understand uh if the two distributed ledgers are not using the same protocol internally and they don't necessarily know much about how the other one works, how either one can guarantee lack of a double spend on the other one right.

B

Good good one as well so that that is that is um that's. In fact, one of one of the challenges is that so, if g1 is trying to transfer to g2, g1 needs to give g2 sufficient evidence that the asset in the dlt, the first dlp, has been either locked or escrowed. So so there's this notion of an escrow where, where, for example, alice the sender could escrow temporarily the money to the gateway or the gateway owner until the transfer and completed?

B

And so so we need a way to enable g1 and g2 to collaborate so that if, if any one of them lies so g1 could cheat g1 could say: hey look, you know, I've blocked the asset and so on. So so the messages that proclaim or these assertions or claims by g1 that it's done its job in locking or escrowing.

B

That needs to be signed by g1 and g1 in particular, so that so that if there's any dispute, g2 can say, but you know hey, you know three messages ago, you said that the asset has been locked all right, and so, if there's any dispute, it goes. Basically, the owners in this case entities called vast basic. You know, asset service providers can dispute this off chain and- and you know recover it, but but that this is. This is one of the challenges uh that that you know.

B

If you want to have an opaque design that the dlts are opaque, then then you have to solve this. You know possible cheating problem between g1 and g2. I hope that helps but yeah. This is this is what this is. Why we're trying to have a mailing list is, is you know this is the? This is the kind of topics that you want to talk about, but I just.

I

Worried, thank you that sorry, it just seems like that. um Your claim earlier was that you don't want the protocol to know anything about, say the value of the asset. It just seems like that doesn't line up with what you just described, but maybe I'm misunderstanding it. It's all. It's also a funny hour for me. So maybe I'm not.

B

Getting it so so so the the g1 needs to just use the lock or the escrow example. So so, if, if there's an asset representation on dlt one, you know here's, you know uh 10 units of this particular asset and uh the asset is described by the profile, there's so there's a pointer or hash to the to the profile file somewhere. You know it's json file, and so g1 is saying that hey uh I have made.

B

I have disabled temporarily disabled access to this asset representation on glp one while the transfer occurred right, and so so so that asset, you know, 10 units of this asset is now unavailable to anyone on dlt one and so um uh g1 now has to transfer that to g2.

B

uh You know in using you know a commitment protocol such as two-phase commits, so that there's no ambiguity and at the end of that transfer uh now that that that asset has to be created, the same representation or equivalent representation has to be created by g2 in dlt2 right and once that happens, the asset has to be destroyed or distinguished, extinguished in dlp1 and and created in in dlt2 right. So that's how the transfer occurred it it it is, it is destroyed in dlt1.

B

It is created in dlg2, that's kind of the model, but we're open to any kind of other model. If you have any ideas about, you know, what's a suitable model to to to actually do asset transfers.

A

Okay, phil go ahead.

A

You you, I can't hear you, I don't know if you muted, via the headset or something else.

A

You seem to be unmuted via mythical.

A

But so it could be like.

A

No still nothing you're.

B

A

B

Your question phil type, the question in.

G

J

For a lot of people, so uh there's a there's, a medeco outage right now and um not everybody can get into the jabber chat.

B

Use the mailing list phil, I'm.

A

Working okay: let's: let's move to wes and stay stay on audio, just to try phil to see if you can get it to work. Yeah.

G

He can he can start talking if he interests me. That's great. um So a couple of things with relation to the g1 g2 interfaces. I've thought about this one. It's unclear because you've used generic terms of g1 and g2. If these are supposed to be anonymous gateways that don't necessarily have to know each other or whether there's a business relationship between them and there can be something.

B

No anonymity, no anonymity. Sorry, I should have put that on a slide, so gateways are owned by if you read the architectures they're owned by legal entities. So if you want to, if you want to transfer legally recognized assets, you have to be legal businesses today, right, okay, so.

G

B

We know, in fact, in fact, that you know I'm saying, and people might hate this, I'm saying that the gateways need to have device identities, which is why I I cited the rats uh work and I I dev id that michael richardson is is doing is because the gateways need device identities.

G

Fair enough, the other thing that I think needs to be carefully considered is uh blockchains have different levels of of a non. Not. I can never say that word of how well somebody can remain anonymous within the blockchain right, so the instant that you actually possibly do, transfers across it. You may actually disclose, and and in an identity across that that that is a ramification of actually doing that transfer and right. So so.

B

No great great question so so uh so that stuff occurs. If you look at the architecture drop in phase one so so right now there is a raging debate in in another world in another set of calls that I attend uh and it has to do with what is called the travel rule.

B

So the travel rule follows from the banking secrecy act in 1996 when what the travel rule basically says that if you do correspondent banking, so if I go down my street here go to bank of america and I say: hey, could you please transmit you know a hundred dollars to where's, actually make it make it bigger ten thousand dollars to where's in in tokyo bank of tokyo, downtown tokyo right. So when that happens, uh bank of america has to transmit my information. Personal information, which is first name last name.

B

Telephone number home address account number at least so, I'm the originator. So that's the originator, information. The tokyo bank bank of tokyo needs to send back to bank of america. You know the the first name last name, an account number of the beneficiary, in this case say where's in in tokyo. Right and- and this has been going on for 30 years now- this is the standard mechanism to do correspondent.

B

Banking, so what's happened now, is that the organization that that defines the standards and the policies to do that called the fat of has just declared last year that you know any kind of transfer of value needs to follow the travel rule.

B

So that means the big crypto exchanges such as you know, you know, coinbase the probably the largest one kraken if they transmit any kind of value to another exchange in uh you know in tokyo they have to implement the travel rule, and this is a headache, particularly this if the uh owner of the keeper is anonymous on the sending site.

B

So if the originator is is saying it's anonymous, the question is: should should the exchange actually fulfill the request and actually transmit to tokyo, because now the exchanges are going to be liable legally and they could be.

B

You know shut down by the sec any time you know, for you know, failing to implement the travel rule, so so so in our model, we're assuming that all of that has occurred in phase one that that's out of scope for us and that in fact, um the originator entity, the beneficiary entity, the gateway owner, a g1 owner, g2, owner unknown and they've completed the whole. You know funny handshake to do travel rule and then our work really starts in phase two of the architecture draft, but very good question. It's actually quite a major issue.

B

Today, hey kathleen.

F

All right, thank you, hi, thanks for the presentation- and I think we're over on time. So I just have a quick suggestion before uh francesca asks. The questions um have you touched base at all with uh sharon goldberg.

B

uh At the bu yeah- yes, yes, I I uh I have I I know some yeah quickest. Yes, let's you know, I I shouldn't take it off.

F

I've done a lot of work in this space, so yeah.

B

The commonwealth, crypto yeah, I know yep great. Thank you. Thank you sure.

A

Okay, so we are out of time and uh we don't have anybody else in the queue so just information. A lot of people have had problems with mythical, so whatever happens today, we for sure have to get more input in the meaning list.

A

So but we've heard so far- and please uh correct me- anybody my co-chairs, the 80s, if I heard wrong uh support to um create a main list for more discussion and discussion, is required for for.

A

Development so to.

A

H

List, in fact, listed at the bottom of this slide.

A

Sorry, what did you say.

H

I said: isn't there already a mailing list listed at the bottom of the slide that.

K

B

K

H

K

Mailing list is live.

H

So so I I guess my point would be: let us do nothing and if this mailing list actually shows substantial amounts of interest- and um you know and an activity that, like we think, was credible, then we can raise the question of something else.

A

Yep, that's a good point. Yeah.

B

A good point, thank you. Edgar.

A

Yes, so the dispatching outcome will be uh create a mini list which has already been created and redirect discussion. There.

J

Hey um so I know some people are having trouble with the chat here. There's also an authentication problem happening with meet echo, and um so we're gonna have to do a vm reboot and it's gonna take all of the sessions out for about five minutes and that's gonna happen in two minutes.

A

J

A

No worries and good that we were at the end of this topic, then so it will not kill us main discussion.

K

Maybe francesco we pause for the reboot and we come back in what so it's five minutes so like in 10 minutes and get the next session started. What do you think.

A

Yeah, it sounds good. uh I hope it would take less than 10 minutes or do we have any information about that. So it says: okay, five minutes, plus two minutes yeah. Okay around that, let I'll be back here uh in let's say at the top of the hour I will set slides so this this topic is concluded and we have a dispatching outcome or that will have to obviously be confirmed in the main list as well.

A

A

Great talk to you in five minutes.

K

Thanks francesca.

F

We have almost everyone back yet, but not francesca, so we'll give her a moment to.

F

F

Having trouble joining with the next presenter share their slides so that, hopefully, by the time she joins, we can just get going or I will introduce you and we'll get started.

K

Additionally, this is roman speaking. Media echo team is recommending uh that you reload your window or close your tab and kind of try again if it's not working for the auto.

L

Refresh, I am back sorry about that. Oh that looks great. Thank you.

A

Yes, shimon: let's go, let's go ahead, we're a bit late! Now, with all this uh that is happening. Will you be able to share the screen or should I do that.

M

um This is truman. Can you hear me, okay,.

A

Yes, we can hear you.

M

Yeah, if you don't mind, could you share my.

M

A

You should have slides now.

M

Great okay, so I'll get started, I'm uh schumann huck, and this is actually a joint presentation with my collaborator ash wilson, who will also be speaking in the second part of the talk. So if he could, I don't know what he needs to do, whether you need to guys need to promote him to speaker or whether he can just join himself or be prepared to do so. That would be good.

M

um We would like to talk about the general topic of gain authentication for the internet of things and this being sec dispatch. I assume folks are already familiar with dane, but just in case you aren't.

M

The high level summary is that it's a protocol that uses the dns and specifically signed dns records to authenticate x, 509 certificates and or public keys. So next slide. Please.

M

So some of the topics we're going to cover today are listed here, we'll go over some uh background on pre-existing work that we're picking up again.

M

So this is a dane for tls client authentication, for which there are a couple of drafts that you may have seen announced on the mailing list recently and we'll summarize past engagement on this work and who is interested in advancing it. We'll also mention some upcoming work that we're planning to do and what we're hoping to get out of the discussion today is where, in terms of ietf venues, we might pursue this work and also to generally get feedback and recruit others into helping out. If there is interest in these topics.

M

M

Slide: okay, good, um so the two drafts that we currently have were originally developed in mid 2015.

M

The first tls client authentication via tlsa records, specifies how to do dain, client authentication in tls, and the second one defines a new tls extension to convey a client stain identity.

M

The original target use cases were one iot device, authentication and second authenticating clients in smtp transport security. For the second case, you may be aware that that's an area that has already seen some uptake in day and authentication on the server side.

M

um We presented this work back in itf 93 in the summer of 2015, in the dane working group which existed at that time, so provided a pointer to the slide deck for that presentation.

M

There was quite a bit of subsequent discussion on the list around that time, but then the dane working group shut down because it had finished its um original charter of work and the authors didn't really have the time or energy to continue pursuing it. But uh in the intervening years, where I I'd say, we're approached pretty regularly by miscellaneous parties, many of them in the iot space about reviving and continuing the work which we are finally planning to do um so next slide. Please francesca.

M

All right so I'll give a quick protocol summary. Now. The tls client has an identity in the form of a domain name, a public and private key pair and a certificate binding the public key to the domain name, and there is a corresponding tlsa record published in the dns.

M

The tls server sends a certificate request message in the handshake extracts the client identity from the presented certificate, obtains the tlsa record and validates it against the certificate or the public key in the certificate, and we also have a new tls proposed new tls extension called dane client identity.

M

It has a couple of purposes uh first to signal support uh for this protocol, which can actually be done with just an empty extension, but it can also be used to convey the actual client's dns identity, which is needed to support, for example, tls raw public key authentication, as described in rfc 7250.

M

The draft currently mentions using ech encrypted client hello, in the latter case, to protect the privacy of the transmitted name, and that part is likely going to change based on uh discussion. That has happened recently. So eric riscorla has reviewed the draft on the mailing list and made some suggestions that we're considering in tls 1.3.

M

We can actually place these extensions in the certificate request and certificate messages which are both encrypted rather than in the client, hello and server hello, and then we don't actually need to resort to ech to protect the first flight data from the client. Then the remaining question would be what to do about tls 1.2 support.

M

um There was another suggestion about modifying the extension data definition to properly allow extensibility, and there have been some back and forth comments about that list. That need to be sorted out too next slide. Please.

M

So the newly refreshed versions of these drafts have a few other small changes from the original versions, and I'm just going to quickly summarize those the main two ones are simplification. Originally, we supported two subject: alternative name fields in the certificate: dns name and srv name, that's rfc 4985, so we now specify only dns name. Srv name is really as far as we can tell not used in the real world at least not yet, and if we need to specify service specific identities.

M

The dns owner name, format in the tls record tlsa record can easily encode an application specific label which it already does in one of the proposed formats in the draft. The second one is relaxing the record name format. Originally, I think we were too prescriptive with the format and that aspect of the draft caused quite a bit of arguing on the list.

M

Different applications will probably prefer different formats anyway. So now the draft just recommends what we might think could be widely applicable formats but allows others.

M

So the other part of the work that we want to discuss is we want to expand the scope of the dane for iot work, so, in particular, object security applications of dane there are quite a number of folks in the iot space that would like to use dane more generally for object security, so neither of the currently defined records, tlsa or sma are well suited here.

M

Tlsa currently is defined for tls channel authentication only and s mine, a is for is object, security for email applications and further has a record format that is defined in terms of email identities.

M

We could of course, propose a new rr type, but that means a much longer development in the adoption cycle and tlsa is already widely known and in use, and the proposal on the table, which ash will talk about in much more detail, is to extend its scope to cover this use case, also where we also would like to use dns and dane more generally for certificate discovery, and I'm going to defer that part of the discussion to my co-presenter too um next slide. Please francesca.

M

As for who wants to advance this work? uh Well, the authors naturally, but there's also quite a bit of interest from colleagues that we uh have in the past and are currently speaking to at places like nist, icann and the laura alliance. That's an alliance of lp1 device manufacturers and more so at this point I'm going to switch over to my co-presenter. But before I do that, I wanted to see if there are any questions or comments on the currently published drafts about dane tls client.

A

Authentication and let's go ahead.

N

Hi guys how's it going uh this is elliot. I just had one quick question about your drop, which was: can you say more about the iot aspects that you expect? You guys talk about it in the draft, but it's I think you spent about a half paragraph, and could you elaborate just a bit? Oh.

M

Yes, we definitely can so I I think what I'm going to do is I'm going to I'm going to defer to ash because he's going to talk about the iot motivation and use case in much more detail, so I think you'll get your answers there elliot. Thank you very much.

O

All right thanks a bunch. I think I can take it from here. This is ashley thanks shimon go for it. um Can we advance the fly? The uh slides, please francesco, uh so to sort of frame our thinking on iot device identity, um it's a in a very basic sense. A digital identity is a name and a way of proving ownership of a name and the um and the value of any sort of identity, strategy or identity system is how widely the name is recognized and how resistant that system is to impersonation attacks.

O

The challenges with iot, specifically, um is you know with decoupled applications? uh It's certificate discovery becomes difficult, you end up with proprietary apis that are operated by certificate authorities and the consuming the message consuming. Application that needs to authenticate messages across a decoupled application then has to interact with that certificate authority consume and synchronize those certificates. So that's one challenge um the there's. A problem of subjective entity names that we oftentimes see within um you know within device certificates and you have a possibility of namespace collision.

O

Do you really only guarantee the uniqueness of a name within the scope of a certificate authority and uh and that's another problem that we seek to to mitigate?

O

You know one of the ways that the industry is trying to mitigate the problem of um you know going across routes of trust is we're seeking to solve that with solutions like brewski right, where you can automate a great deal of the onboarding process from manufacturer issued, pki to locally issued or enterprise pki.

O

You know, together with all of these other problems, the fact that these platforms are really quite constrained and the example that I'll give is the the espressif esp32.

O

That's a really very common and widely used system on a chip that you often see shipped with about four megs of ram. If you want to put the browser, the browser ca bundle on it, you know for tls, just the server authentication aspect, then that's 1.2 megs that you're dropping onto a four meg flash chip, and so it doesn't it's I I guess an inelegant is a is a pretty good way to describe that aspect. um Could you advance the slide? Please.

O

um So dns is the my is definitely the most widely recognized namespace on the uh on the internet and public key authentication is uh is quite resilient to impersonation.

O

Dane gives us the ability to use these two together. It's a way of binding a dns name to a public key, and this gives us an identity system. That's resistant to collisions even across certificate authorities, because even if two different authorities issue against the same name, whichever public key is associated with the name and dns is the one that wins you don't have to worry about. You know proprietary um interfaces with cas proprietary apis, because the sdk for that interaction is already baked into the operating system.

O

um You can attribute. um You know dubai uh device behavior via the dns hierarchy, to whoever actually owns the identity, um and that also gives a way to sort of repudiate that identity too. You can tombstone the record or you can just delete it if that device should no longer be trusted and the current public key is always in dns. This can, you know, can fit in with certificate rotation policies.

O

um You know and enable better um uh sort of identity, hygiene, and then you don't actually have to distribute certificates uh to um to authenticating parties when you considered like a decoupled architecture.

O

This is a discovery mechanism as opposed to distribution, and the analogy here is sort of like the the host.txt file originally right that this sort of prompted the need for dns is because it became unwieldy to move around this host.txt file. It was enormous and the rate of change was high, um not exactly the same but similar.

O

We have you know managing certificate authority. Ca certificates uh for validating certificates can get that unwieldy for devices. So moving from a distribution model to a discovery model can bring some elegance and simplify some things for a certificate discovery in iot next slide. Please.

O

So digging a little bit deeper into the implementation aspect. uh This actually borrows from uh what we saw in the uh freeland barnes uh certificate id uh format for devices. uh This was a draft um a few years ago that was presented, but it's it suggested the use of an underscore device label.

O

um You know within the certificate- um and we think that actually fits pretty well here, because it gives us a delegation point or a point beyond which we can delegate. You know to either a third party provider, or you know, to a uh to a specific system.

O

That's under the control of whoever's, managing the device identities for a uh for an organization and uh similar to how the s mine, cert label works in 8162.

O

um Everything under s, mime cert is a human identity, and you know in this sense this would be everything under underscore device would be a device identity. uh Another difference in the two is this: doesn't carry the the complexity that 8162 has for hashing. The email address local part to get something that's compatible with dns um devices would just have simple dns names, and then you could have uh sub identities. If, if you wanted a device to have multiple certificates associated with it, then you can use um you know.

O

Different um labels uh say underscore labels on the uh you know on the far left of the dns name. You know for smtp clients uh things like that. The record type that we propose to use is tlsa.

O

There's no need to change the format of the record to serve this use case already works really well, and this doesn't have to work exclusively for iot.

O

uh That's we've gotten some feedback that this might actually work pretty well for other applications, microservices and things like that, and since we're binding this to the universal namespace of dns, then you could actually pretty easily and simply describe trust across organizations where you may have a client within one organization. That's reaching out to a service, that's presented by another organization, and they can do mutual tls using dane next slide. Please.

O

um There are a few places in the stack where we think that this could that this could benefit the ecosystem right. There's, network authentication, uh transport authentication, further up, there's message, authentication and wrapping all of this together, you get an authorization policy that starts looking like network access control lists, I'm a former network engineer. So this is just sort of how my brain works next slide. Please.

O

Digging into the network authentication use case, um this can be used to simplify radius configuration um radius, often times for each tls involves interaction with certificate authorities and managing all of that stuff. With dain.

O

It becomes as simple as managing a list of entities which are allowed to access a given, vlan or um ssid, and so you know, your radius server really only needs to contain a list of identities and it uses those against dns to pull the public key to uh to authenticate the device, as opposed to having to manage a certificate authority.

O

The challenges that come with the subjective naming that can come along with that. This. um This we think really cleans up uh the use of uh eeptls and can lead to wider adoption of uh x.509 based authentication for network access, and it also makes this the support for raw public keys. In that case, a little simpler, too uh raw public keys. um You know, which is essentially a certificate with all of this stuff, like the issuer information, the issuer's signature, the entity name and everything else stripped out of it.

O

It's just a public key, so it doesn't bear all that other metadata, that's oftentimes, used to correlate. You know, with the named identity and using dns to host those raw public keys, takes the burden off of the network administrator or the radius server to correlate the name with the uh the public key. So we think this. This simplifies that as well next slide.

A

Ash, please just gonna interrupt you quickly, just to uh let you know you have around 10 minutes left and I I suggest we move quickly to the discussion part which is most interesting to to get to the dispatch outcome.

O

Certainly, all right, um the uh the transport authentication aspects we've already covered in some detail and that's just being able to do mutual authentication between two entities, regardless of the the certificate authority. This we think works pretty well with multicast dns.

O

As a companion technology, multicast dns gives us the ability to you know dns service discovery on a local network to announce this is the service I'm providing. This is my identity. The identity can then be confirmed using dane and the public dns. um You know as a part of that process for authentication, and then you can very simply describe trust. As you know, this device may act as a client with this server. It can be objectively interpreted, it can be interpreted by humans audited.

O

Just becomes a lot easier to you know, to understand and to parse policies from a machine and human aspect next slide. Please.

O

Object, security and I'll go into more detail on this in a little bit. um You know the challenge. One of the biggest challenges with object security is getting the certificate to the authenticating party and then also getting the you know the public key to the sender. If you're trying to do end-to-end encryption so using dns as that certificate or public key discovery mechanism really simplifies that and again you get the benefit of working across cas and then policy in this case can be described. As you know, cinder may use middleware to reach recipient.

O

It starts to look a little bit like a policy route. Next slide, please uh life with dane. uh We think that uh identity suppliers will be able to um to ship more useful identities, and this could be in the form of sim cards. You know or uicc's.

O

um You know. Even you know, tpm's trusted platform modules. Things like that uh can have uh identities that are uh authenticatable using dns. um You know as soon as they're plugged into the device and then implementers get the benefit of being able to roll these devices out more quickly uh without having to re-key to enterprise.

O

Pki and application owners can get the benefit of a standardized application or um authentication protocol, um and hopefully this will lead to a state in the ecosystem where, um where you can choose best of breed components, uh you don't always get you know. Sometimes you have to buy your imaging devices from the same company that produces the software you use for computer vision and they're, not always good at both you just kind of have to figure out which one's more important and go with that.

O

We're hoping that this opens it up for um for application owners to pick best of breed equipment too. Next slide.

O

Current work centers around using dane for mutual tls. We think that you know beyond mutual tls there's uh there might be a benefit in oauth 2, which supports mutual tls um and eat tls. We think that that may uh that may work with little or no modification once the once. The tls library supports the use of dane client certificates next slide. Please.

O

Upcoming work, uh using dane specifically for certificate discovery across uh decoupled applications. This is something we refer to as dain light uses tstls the tlsa record to represent the certificate and still uses pkix to authenticate the certificate, um and we would. We would propose this as a separate and very focused use case um with a different certificate usage mode called pcxcd, the ultimate goal we want dns sec everywhere, but because dns sec adoption is so so sparse.

O

That's that's an inhibitor to adoption for this, so we think that using it like this, we can still safely use the record and authenticate what's coming across and incentivize the use of or the further adoption of, dns sect down the road, because if you can use the tlsa record specifically for authenticating messages in a decoupled application, wouldn't it be really nice if you could just use that for mutual uh mutual tls authentication?

O

Well, then that then it becomes a simplification and there's a usability benefit to adopting dns sec beyond the security benefits, and you can then turn dns sec on and you can start migrating these over to.

O

The cert usage of uh you know one or three or whatever, so I realize that we have covered an awful lot um and I think we can kick to the uh you know. I guess the question you know now is: how should the uh you know, how should the work continue and um you know, should this land with the tls uh group with uta dns op, or is there a better working group? This could land with and and now is a probably a pretty good time for q. A.

A

Good time to start a discussion, richard did you want to say.

E

No, I was just going to say the same thing. You just said.

A

Good uh there is some discussion in in jabber going on which have been okay, phil go ahead. Let's try this.

M

A

O

No, I can't hear you.

A

Was working and then he stopped working.

A

Phil can't hear you.

F

I can't hear you either.

A

No, it's not working um elliot, went into the queue.

N

Yeah, please should.

A

N

Do you want me to go ahead.

A

N

Okay, yeah we're having this pretty lengthy discussion in the chat uh phil. We can't hear you so just just bear with you bear with us, but um you know: there's there's a couple things tied together here. um I suspect uh people need to understand quite a bit more about this proposal and before before it goes forward. For one thing, I have lots of questions about dependencies uh relating to it. um It's interesting, but it's also one of something close to a half dozen similar mechanisms uh that each uh offers a slightly different claim.

N

So we probably need to consolidate those discussions a little bit. um Maybe the thing to do is to push it into a boss. Maybe the thing to do is to uh bring it into the the uh pondered, iot ops group for discussion and then dispatch from there with these other mechanisms.

N

uh Those were the thoughts from I think I mentioned some of that in the chat. I'm not sure uh what other people think, but at least the idea is worth pursuing a little bit to to clarify what claims are are being offered what what environments can work and what environments it can't work. And how does it compare to the other mechanisms that are being put forward?

N

We did have a little bit of these sorts of discussions in the side meetings for onboarding, but we haven't really carried those forward, and maybe we should because there are also a bunch of mechanisms outside of the iatf that we need to view in this context, especially in the context of iot. Thanks for letting me blather on a little along here,.

M

So elliot is uh iot ops is that a existing working group or a proposed proposed one.

N

And is that where.

M

You were proposing to have the discussion.

N

Yeah it's proposed and- and we have to run it by rob wilton and you know, maybe that we should um you know, have that conversation. You know as time goes on, I'm not sure how you want to handle the dispatch. Here, though, I realize that timing is not perfect.

A

Okay, thanks elliot anybody else who wants to come to the.

A

A

A

Okay, so I I heard go ahead, richard.

E

Yeah, I think I was going to go in the same direction. You were and try and kind of start summarizing based on the discussion on the audio and the chat.

E

Oh, we have one one last person, thank you roberto did you want to say something.

E

uh I guess not so um yeah roberto feel free to turn on your audio if you can get that working. um So I was going to try and summarize it sounds like based on the discussion in the audio channel here and on the chat that um there's a fair bit more sorting to do here, um so this might be uh best suited for a full up off um to as early as pointed out, collect some related work and and get a more uh holistic view to this uh before we uh charter up a specific solution.

E

So I I would put that forward as kind of a proposed resolution for this one.

A

Anybody's strong objections to both is there a discussion.

E

A

E

I was going to say that that would be another another precursor we could do is set up a mailing list to discuss these sort of um authentication uh requirements.

A

So eliot is suggesting this iot onboarding analyst, so that sounds good.

M

Okay, that's that's an existing mailing list or where you're proposing.

A

That okay steven go ahead.

P

So I wasn't clear what the topic of the buff richard was imagining. What would.

E

Be I I would probably defer to other folks with a little more expertise in me here, but I would I it sounds like folks had in mind um something slightly broader than just this topic, I'm covering some um uh slightly uh broader frontier of uh different iot authentication and identity, provisioning technologies that are out there, but.

K

I see elliot in the queue now.

E

N

Yep, you you, you just said it pretty much there richard, um which is. uh We should look at this mechanism. We should look. I think, at uh the mechanism that uh dan harkins and um uh and our colleague from from malaysia have put together, which is a tls pok draft which is related. There's t work, that's related and, of course, there's all the anima ace work that that needs to be considered as well, and I think you might have some related work as well. If I understand correctly.

A

um So michael was writing in the chat. I think you is probably richard. Yes, um no non-working group forming buff, I I don't know if we discussed the the non-working group forming or working part of it.

A

A

Ted or roman roman go.

Q

Ahead, so I was going to say, I think non-working group forming is probably right at this stage, because one of the biggest problems you actually have is: how do you get unique names to these devices that are usable in this context, for the people who want to identify them- and I think both phil and and ecker kind of laid out in the chat good reasons why the names they're commonly known by simply won't work here, and so I think, without that framing discussion first, going into the methods, isn't going to help a lot, because you're arguing about the utility of something attaching a trust anchor to a name that isn't unique and that's really problematic in all bunch of ways.

Q

So I think a a non-working group forming off that that took a bigger framing question and then invited people in to describe why their solutions took their views of it would would be more useful to make progress here. Thanks.

M

Yes, thanks for that comment ted, so I think um uh we uh are expecting the names to be unique, so there's there's a provisioning process by which unique names are deployed on the on on the devices. I don't know if ash's presentation touched on that, but um that is at least our expectation.

M

Yes, that's correct.

Q

So I think that is your expectation, but I think the huge number of these devices that expectation would not be met.

A

Okay, correct stop this discussion here, uh but I I think roman wanted to say something before I don't know. Roman.

A

A

E

I think roman I lost uh lost mytico connectivity, I don't know.

K

E

And ben cadek is on the line. It's our other id.

D

A super clear outcome, but I agree that there's a lot of things going on in this space and um at least I don't have a great understanding of even the scope of the work that was presented here. So it's definitely in a you further discussion, whether that's an email list or off. I don't have a great picture myself.

A

Okay, so I would say the conclusion from both um next up is both and continuing. The discussion in mailing list proposal was.

A

Too high on the chat.

A

um Someone can someone post uh what mailing list was again.

A

It was an iot ops but iot onboarding. Thank you. Thank you. um So we discussed we continued discussion. There um waiting the buff opinion there as well, and thank you ash and schumann for presenting.

M

uh Yeah thanks. Can I just ask one quick question before we move on go ahead, so the we'll start, the discussion on the iot onboarding list and then the proposal uh to submit a buff would be, if I understood elliott's suggestion correctly earlier, was to cover the dane for iot topic, as well as a set of related uh protocols that intersect in this area right. So if I could ask elliot to summarize the set of things that he mentioned, the related technologies and protocols, uh maybe.

A

An email to the.

M

Sector specialist- that would be good.

A

This is a good point to to remind everybody that in this working group, we actually dispatched the work to.

A

Whatever dispatching outcome we recommended is actually done, so um you can always come to the chairs too for more indication of what that meant. But yes, let's take it off this offline.

M

Okay, great, thank you.

A

Thank you next.

A

C

All right, I'm.

C

Trying to share my screen here.

A

And nice to see you as well.

C

Great, so you have my screen.

A

Yes, we can see.

C

The slides good, so thank you for the opportunity to uh present the signature. Validation token, um as we mentioned at the beginning of the meeting. This item was briefly uh presented and discussed at the security dispatch knight f107.

C

One of the news here is on the first slide is that russ housley has joined me as an editor for the isdf drafts that are actually now posted to the itf. We have three drafts on this, and so let me go through quickly and briefly.

C

The goal of this work is to provide a simple solution for a validating signature in the distant future. This is an area where there is a great need and also a great potential of doing something that is not available through current solutions. Today, um the history of this work is that it started up as a swedish government-funded research project for archival of electronic signature.

C

What do we need to do in order to have effective archiving of electronic documents? um There's a huge potential savings in be able to do that.

C

This work got adopted by the swedish agency for digital government and now is a first standard for how to do this. Officially in swedish government work, it has been developed in a public available open source and it has gone into production. Also in the education service. I will talk a little bit more.

E

C

That uh it's a signing service for the swedish education and the violence and and for the school systems in sweden, and uh now we're approaching this in the itf for standardization, not rubber, stamping, but we have a version 1.0 of the protocol and we would like to develop for 1.1 within the iitf to have itf uh full in in control of what happens and change control of that next version of the protocol and the important requirements that should be satisfied with the solution is.

C

First of all, there are solutions that do not integrity, protect the document that they are being protected here, but this solution needs to fully integrity, protect so that, if anything, changes in the document that's been archived. When you pull it off, this evidence should not work anymore. You need to be easy to implement. uh There is a great need for simplicity here. We need absolutely predictable outcome. This is nothing that is not currently provided by current solutions.

C

If you validate the signature today and you archive it, and you pull it out ten years from now, you might come to a different conclusions, just following the validation procedures, because some external information has or or condition have changed.

C

We want to avoid size explosion and especially cascading evidence collection. um Signatures are supported by external evidence and when you have external evidence that require another piece of external evidence, and that requires another piece of external evidence. You get a cascading effect that we need to avoid. um We want to avoid repeated storage of lars calmly validation objects if you're, storing, 100 000 documents and all needs support over 50 megabytes crl, then storing that 15 megabyte crl in each of those 100 000 documents is not very efficient.

C

um We want to provide fast verification and then, more importantly, it should all work offline, not because we don't foresee an online capability in the future, but anything that needs to be available online might not be available in the future and it must be compatible with current document parsers, a signature, validation software. It should not interfere with processing these documents in any software that doesn't know anything about the solution.

C

um It is up and running in in production version 1.0 in edusign, which is a solution provided by zoonet, levieux and son. That is well known here.

E

C

Is handling this uh service and you're free to approach him about the the choice to to use this, and this is used to ensure that everything that is signed in edusign can be archived and be validated in the future, which is a key feature that is required by the educational system in order to use the solution.

C

um This is not different using the signature. Validation token is not different from any other signature validation because they all require some sort of external evidence. No sign document solution can validate signature in a self-sufficient manner. um In the easiest case where the signature certificate still is valid, uh I still need to know is the signature not revoked or not, and if this is revoked?

C

I also need a time when the signature was created before it was revoked or not in order to do signature, validation, even documents where the certificate is valid after this certificate expires.

C

I need to know a time when the signature existed and I need to know the validity status of that of the certificate at that time.

C

Then, when the algorithms are no longer trusted or if the key has been exposed or anything like that, I need more information. I need still a time where the signature existed.

C

I need the validity status of that time of certificates and other, and I need the data that it was actually assigned, because I could have altered that signed document that made that fit the signature. So I need to know actually what data that was signed at the time and I need to know all the certificates that were used and it would help also know to know results of prior validations, and one of the problems with current approaches is the cascading evidence collection, and that is the main area of improvement. Where we're trying to fix.

C

With this approach in the currency situation, I tried to validate the signature and that signature is supported by cert and that cert is supported by chain and to validate that chain. I need to support by lcsp tokens that is supported by cert and that ca cert is supported by crl and then in order to know a time when this was valid.

C

In case something happens, I need a time stamp and I have the same problem with cascading evidence and they all end up in a trust anchor, and I may know if that trust anchor is trusted today, but I may not know in five years from now.

C

If that trust anchor is still able to be determined to be trusted and then to have the long-term validation, I need to timestamp all of this information by a a a we call a a archive time stamp, and this archive test needs to be stored for by supporting evidence and since the time stamping authority does not see the document or don't know.

C

If anything else is valid, it's only making it a a statement of this existence existed at a certain point in time, and if you need new evidence, you need to create a new archive timestamps. That includes the first one.

C

The problem here is that any piece of evidence that is not valid in 10 years from now will destroy the whole chain of evidence. This is not like. I have 100 parallel sources of evidence. I have 100 serial points of evidence in anything that is not verifiable.

C

Tomorrow breaks the whole chain of evidence, so the idea is to reduce this and to replace the cascading evidence with one piece of evidence uh in order to increase the predictability of the outcome and and removing its complexity, and that is replaced with the signature, validation, token and the signature. Validation. Token put everything in one evidence and you collect the signature validation token when everything is fresh and can be checked in current time. So the token includes information about whose issue the time of issues the algorithms used to create this token.

C

If there is an expire of the token, and then it has a hash of an assigned document, it have hashes over the signed attributes which is like signed attributes in cms or assigned info in xml. It has a hash over the signature value and the hash of the certificates that were validated.

C

Then we can add information about verified times that we have verified and how we verify them, and also we can include the results. The new now how we use this is that it's free for the validator to use whatever part of this evidence you feel are necessary. You can use only the claim that the certificates were valid and validate the signature while it can be validated, but you can also choose to rely on the whole conclusion here, but you can essentially replace the need for all the cascading evidence with one piece of evidence.

C

It's very time, space efficient, I'm sorry, it's spacious space efficient. So this is the example of of the format with compressed information. If you show this, how this looks live in xml, it doesn't take very much space, it's extremely much time space efficient than, for example, storing, crls and ocsp responses and certificates of all cascading evidence in a signature.

C

The validation process is pretty simple. You look at the document if it has a validation token, you validate that. If it doesn't have a token or you can't recognize the token you go to the traditional validation process, you come up with a solution and in the validation you choose whatever you think you want to use from the supporting evidence. In the validation token, in order.

E

To do this, if I just sorry to interrupt that, you have two minutes left.

C

Okay, um so basically we have profiles for pdf, xml and jobs, and we have um drafts on the internet.

C

uh We have open source available and we have a test site where you can test, update and update upload any european validated signatures or qualified electronic signatures, and you can download this document with a validation token and once you're validated you can revalidate it with the signature, validation, token enhanced process. And if you look at this in the pdf processor, you will see that the signature validation token appears here just as another document timestamp um the iitf.

C

Why is because this is first of all, based on a jot format that is as a route to the itf, and I have done similar work in the past and now we think that lamps, because it's it's cms related, would fit into the lamps working group to to work on there and um questions. So that's all I needed to say about it.

A

Thanks thanks steven, um so comments keeping so so this this work was dispatched at idea. Format. Seven with more the outcome was more need for discussion.

A

And I'd like to hear if people think that um things have changed enough, so I I am hearing that. Obviously the authors think things have changed enough, so that there should be a different outcome today,.

F

Yeah, so we don't want to change the dispatch. um You know what has been done, but we do want to hear the feedback in case something has changed. So if people have comments, please come to the mic.

A

And also there is a lot going on in the chat, so either people in the chat come forward. uh Roberto, go ahead.

F

Thing in the chat so far has um you know, said anything that suggests a specific working group or anything along those lines. So can you hear me.

A

R

Oh thanks uh um roberto. I know that there are some other organizations in europe that are trying to standardize a json profile for storing signatures. Just like ei das profiles for jason and something I saw before was quite similar of what was presented, and I was guessing if you had any um talk with them or if you managed to put in your specification all the ideas requirements. I think that this work is interesting and I will be interested to talk whether it makes it into the idf or not.

C

I could I could answer that uh very well. uh The the work done in cesi is is another type of it's, not this kind of solution, but it's it's another type where you include all that cascading evidence in the signature. They all have that for pdf, and that is completely complementary to this work. You can use that kind of cascading evidence into doing the conclusion of creating a signature validation token.

C

So there is no conflict here. They do standards, how to include cascading evidence in a document- and this is another approach, and this is completely compatible with anything that is designed in the itis.

C

There is no preference in the items how long-term validation should be done.

A

Okay, really quickly hank. We have two minutes left.

S

Okay, uh smelly fun.

A

S

Okay, thank you. So I hope I hope you can hear me um so I I I really like this work. It's uh basically offloading the burden of appraisal of old stuff to a another entity. Now you can trust this entity. My question is you're using tokens here and I have to admit I I fast read the document, but I did not find it. How long is this? Are these tokens supposed to live? Is it like a service?

S

You can request them if you receive something old or is it like a substitute and it lasts for years because token too, big or short-lived.

C

So that's a that's a policy decision, but they are not assumed to ever expire because this statement they do never expires. The statement is this is what I checked, and this is the conclusion using this policy that I came to and and that is a statement that never expires, so you could do an expiration. There is in the standard you could have, but you could also let them live as long as the crypto that supports them is supporting them.

S

Okay, so the uh reliability, the resilience of this service or this entity is higher than the substituted uh authority that was marching for or creating the uh uh sort of the first hand here. Yes, so there's a listen.

C

You can you can replace this one. You can replace this one with another one and you can also replace it with more using different algorithms. If you think that you want to have a bigger bet that this sign with this algorithm will live longer than the other one, so so, uh but but the validation process is exactly the same. If you replace this with the new evidence in the future. Okay, I.

S

Would have yeah, I understand sorry francesca. I will stop you right now because I'm sorry yeah, okay,.

A

Yeah, thank you hank, so this seems to been looking at the chat and reading feedback, uh and uh I I think that the outcome is still the same. It needs more discussion and what probably not continue. I would need a new working group. um So I again, I recommend.

A

In the dispatch mailing list, so everybody can join there and, yes, let's, let's conclude this presentation and the meeting. Thank you stefan, I think uh to summarize, let's see: let's do this real quickly, so for the interoperability architecture for blockchain gateways, so we have the main list blockchain interop, and we need more discussion and community development in that mailing list.

A

For the dain for iot security, we recommend a buff to discuss more and then use iot onboarding mainly list in the meantime, for discussion and for the svt. um We still recommend more discussion in the main list to be created, and all of these will be, of course, confirmed in the sec dispatch mailing list and we hope to advertise a different discussion. We'll ask the different authors to post a thread in the menu list.

A

To do so, and with that said, we are two minutes over and thank you so much for joining and I'll talk to you very soon. Bye.

F

Thank you francesca and richard.

K

Thank you to the chairs.

K