Internet Engineering Task Force IETF 115, 9 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF115-TEEP-20221109-1500

Description

TEEP meeting session at IETF115
2022/11/09 1500

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

A

A

Alrighty good afternoon, everyone, it is time we have a packed agenda, so welcome to the trusted execution, environment and provisioning and for the first time in a while, you have both of the chairs here present and live. So thank you, hello, everyone!

A

So David, my colleague myself named again, um you are attending the tip working group um by now. You should be well aware of the note well, which speaks to the intellectual property um and the ietf processes. I will let you read the slide in the interest of time um meeting tips. The only thing I'll call out, but I think everybody here is following protocol for those in person. Please make sure that you are wearing your masks, keep your audio and video off.

A

um We are running questions through the online Echo queue so for those in person to respect those who are remote. Please get on the Queue before um coming up to the mic. Okay code of conduct I think we're a pretty chill group. So again just keep the discussions. Professional, um okay, so I think we've already gone through this. Thank you, Peter and Chris for being volunteered to take notes um very much appreciated.

A

So agenda bash and uh will apologize to the presenters. We had only requested 90 minutes, as that was all that was needed in the past. So, oh, so, while um you all do get to present, we had to cut your times a little bit short just to accommodate everybody who's presenting. So, as you can see, we have a fairly packed agenda.

A

um We cannot take any new items for presentations, but hopefully this is a time to bash the order, and the time is that okay going once going twice.

A

Okay, so with that we can go ahead and get started and we'll have Ming I presume you want.

B

C

D

D

D

Quicker summary here is a last item, so we have a draft update from uh draft version 18 to 19, and this also has been in last call for several sessions right for Thomas and separate itfs, and then for this update. I would say um they are multiple review. Reviewers comments. I try to address, we have addressed all the comments and I will receive the many feedback.

D

One for the um things here, I need to mention is uh I, didn't know um some of the comments because they were not in a cheap email thread that there was a tracking and I found out from a teamwork group. Page I find several comments and you can see the um from 80 from a circuit directory from Ben and Schwartz and uh from Paul. They are. uh They give comments over old version 16, but still a lot of applies.

D

So we took those uh comments and uh all replied, so they have it and then we have uh Bob Hollis and honest uh comments over uh version 18.. We also have a comment from Roman at the Robert uh Walton, so totally about seven people's comments, and this adds up there's a quite some comments. There's a uh many ones.

D

I would say highlight it's: a one is a Security review, because it's got two from a Security review that was from old version, but there's some still the sum and we um we find still applicable and we made some updates.

D

uh Majority of them are um minor updates, so we'll go with some of them, so I have about that um 18 slides next, let's try to run fast in 20 minutes and we'll see mostly the main ones will talk yeah, the next one, all right. So this one from Ben's comments uh is from old version 16.. uh The main question about the name and terminology about uh trusted application, uh the code toss application and we use ta everywhere and his suggestion.

D

We should call The Trusted component and the second one is about the question he has but um contrasted. It doesn't look right uh objective to maybe it's isolated, so this is the old one. Now we had some email uh conversation and uh also a discussion on the first one about the code. Choice application at TA in a documentary said uh uh three things. First, one is uh protocol spec already using traffic component and the second one is the TA. The definitely I could talk with our definition conversation.

D

We already said this: Choice application, May means application or in some application application component. So we already space for that. Third one said: ta is also common industrial terminology. In terms of term um we uh what's changed we are at, is we add the reference uh in the spec, so when we said application um component running inside T refer that to, for example, a global platform or open source te, they are all called ta and as a trans application. So so we still keep that way and we better with definition, we cover the post.

D

So that's a part of the the terminology aspect uh with regard to word, trust the application words oscillator application or actually component, um we discussed decent, goes that one, it's a still uh right, uh modifier to set, because you trust the um components at the time in stores. Right still is trusted.

D

um So that's for this one. Any questions I'll just move to next slide.

D

All right, then, if you use this minor uh clarification questions, uh maybe you got a nice area.

D

First, one I've been asking for some clarification. Maybe some discussion about what the device owner can do, but I would say this one is was an older version 16 in uh 17 18 later, and we added definition but device administrator for a while and in the device administrator, which is clearly specifies what the the Privileges or rules are the ones the demonstrator has, and the owner has right then, with specify already is that the decision maker is the master demonstrator and, secondly, trust applications.

D

uh Installation delegate to the time right time has a privilege to install or we have a demonstrator so that clarified. Then uh bing has several uh suggestions about the reward change, uh for example, here the right of uh verified rights of developers working from rights as to permissions for rights to Broad right, it's a kind of a loaded eye term.

D

uh Next, one I have some incomplete sentence. It's a that. They, um the installation, talk about key installation, says it's uh needed so that uh untrusted app can continue. So it's instead should say installation of untrust app can continue. I can complete um then there's a one sentence where it's considered confidential, then we didn't specify by whom and from who that uh he said.

D

We add some more information, so we took a suggestion and making a modification in a below the number, four or I said, for example, by whom right, for example, when developer, who want to provide ta without revealing, is equal to others as a case. uh He then I by the way. I would say this uh um comments below I, don't go through by person.

D

I go through sections, Section 1 to section 9., so section one is also common from a romance about uh about the wording, says: danger of attacks or the consuming tax, and we change your word from danger to risk of tax, some just some of that criminology change there, so making them more readable or excellent and next slide.

D

So now, we're just think just wanted to doesn't have much of a comments section. Three uh sorry for the formats, uh since there is a use case, examples this one is being asked say for trusted user interface and the question is anything um example in a mobile device: it's a smaller mobile device. You have trusted feral that is not actually performing The Trusted anode from normal uh OS.

D

It looks like uh it's a theoretical there's no example and then then uh David, you know sex David here the seller has comments yet so we know you for Point of Sales point of sale devices payment devices. Then it's extensive to use that uh need to trust the UI right over the top p and so on. So we uh the changes, we expand. The description says trusted usage interface, maybe using mobile device or point of a cell device.

D

We added that point of sales device there, so he uh for that, because this is a permanent use case anyway. So we should add that so that was added, and next please.

D

Iot use the case again about the examples several classifications actually well. One is uh Ben commented what kind of give example right, which is iot devices that um cannot allow ieos to run a certain accurators and uh Inez Robles um asked as a different one says: what kind of artistic devices fit to run deeper protocol that way. So what's a capable, he was suggesting whether we can specify particular classes, for example, use IFC 7228.

D

um And more uh other discussions, therefore, I just want what classes of iot devices say that RFC 7228 don't really Define the capacities about whatever fit the protocol. What it says in general, we don't specify that we just leave that to adopters right, they can decide and they could check.

D

Oh the code right, the code capacity could resource need that the device will capacitor face to that one now, with regard example uh being asked and there's a multiple discussion from uh Dave, and he has a demo some devices which can provide that brand has replies in a mailing list. So what do we end up?

D

Is a you know as a update in the draft, we added the global platform t as a reference, and we add that example, as it was sitting in a paragraph you can read here, for example, glow plug for T use the term transferred for all to refer to such things, which can be accessible only from T and the concepts used uh in some complex devices today too. So that's as of this comments and next slide.

D

This is the most of the controversial I would say most important. One is update um being as part of Security review. You said: well, we managed the trust anchors. We inspired to trust right. What uh whatever time is hostile time right and Brandon also um has comments from last ITF about the straight description we already have in section 9.5 I talk about a compromise time right earlier was pretty brief. One line the third. We felt that we need any more, but the potential mitigations.

D

What uh uh administrator what a system can do to mitigate this right um as a part of a threat, so there'll be a long revision here as I quoted here. It's pretty long, I guess I, don't need a rhythm through.

D

um The first line is the original one. Then remaining. We added, moreover, say potentially uh candidates as few ideas to mitigate stress what a tip agent a device owner Dimension can do. So. What we added a largely below is that to mitigate the threat, tip agents and device owners have several options. They included, but not a limit to this. We have just a few kinds of that because we cannotic it's also list. Also, implementation, specific um and everyone will say: oh you can apply an echo right to the camera key.

D

So in the right side, so I can limit the uh threat or damage from compromise attack right Echo can control that um or use a transparent, lock, that's more of a company compromise time right and transparator log can um expose um what that ts are using and versus what a Time published, whether they well legitimate time they will publish, or what do they will support. If you compromise the ts are not in the list, it discovers that there's a mismatch.

D

This case a compromise case time case um also I, could use a method, for example, remove the excitation of the time right, reverse other side So today we're going to remote acceptation of device. Two time now you can do time to device as well. In other ways, um there are other ways whether we just list several Fields possible at a likely feasible, a regular Hospital time that we're a Time provider intentionally abuse the devices right abuse digital devices, not a compromised in such a way, but hacker but I would consider.

D

Is we have multiple discussions with um within the authors also uh like Brandon, so we felt that uh there's a hostile time is equivalent to a computer time. It's a special case of a comfortable compromise tab. In this case, the people and team are the executives in terms or management is compromised right. So so we consider it's a um it's equivalent and we use it why this is the same um category come from times right to cover both foreign.

D

Just to make it completely explicit, I think this is just straightforward uh next slide, please.

D

um This was about the classification uh for that who contacted food first. uh This was from Bob Haley comment. uh We said, Pam cannot contact team. The device right time cannot contact a tip agent either for the firewall, for my reasons, with a usually TV broker initiative contact or we have a device tip agent talk with time and a few questions uh says that, uh where the tip agent must ask the broker to initiate time or broke condition only when trigger that right, we can trigger that.

D

So we revised we revised this uh paragraph as it is largely David made a change Dave. Do you want to say you know what tuck this one or I can read here.

A

D

Good I've just read that so I guess you need to speak otherwise, okay, uh so we just says um explain a little bit more. It says it's. A protocol um architecture is a particular highlighted architecture in figure, one a communist case well uh as other less strict restricted by leaving details of this appropriate team to the uh deeper transport protocol. For example, one defined um that David is back right.

D

People over HTTP, um that's the main one, and it would describe uh to explain, says that patient um Rusty, when it is running in a user devices inside devices, one uh firewalls will normally uh does not allow external access to it. So then we usually um we need a kind of a tip broker to initiate right to initiate that contact, or we have a tip agent. So that's a I. Don't need to read a little word by word.

D

um So this is just for clarification is no no different. Major material change. I would say next side next slide. Please uh this one is also uh it's an editorial change. uh Thanks to Bob, Holly um and notice that uh notations as an early I, didn't put the early one. Only one called app dashing one app dash 2 ta. Without Dash ta1 tier two, whether Dash he said online, let's make it consistent. I will use a SIM format right app. We already called the untrusted app. Let's call it UA right.

D

So then Everywhere You stash Time Dash on time, Dash two. So this is this is Kernel one. We I made a minor changes. Everything just uses that format, ta Dash UA dash time, Dash and I want to. So that's the update, um no material change, just a simple notation change uh next slide. Please.

D

uh This one I do need a cloud um Bank commented on the use of a must in multiple places. It would save examples say: implementation must support encryption. Now. The algorithm must support the integrated protection that must, we use a low test. A lowercase I highlight this from here. We you know actually documented. We do not use uh uppercase must rather than some spec or some well. We do use in some respect too, but for the acute document which is not intentionally um there's a debit card.

D

It's a uh comments, uh you know very less online and we quoted here um I guess some part of ieta, which is some people, will have some feedback. They don't always like to use that uh uppercase and we took that feedback. So it's just to use just a normal word regular case.

D

So that explains I think that the main one, the others are uh just a tutorial change. I'll. Just uh let's skip this one. Let's continue next slide. Please uh clever, supported in quick goodness that uh this is from Roman uh Roman um comment: support encryption, his question about encryption for data address, or data in motion.

D

We we make it explicit. We add one says this in question: purpose is to uh used to ensure and no personalization is sending it clear. It's a data in motion protection. uh Mm-Hmm next slide. Please.

D

uh Section 4.5 is good catch by two people. A poor and a robber will both said is a sequence and I. Don't know really right and a really nice that a good catch here, but he said we will adjust it. It's a it really says. When the installation, normal app happens, it felt.

D

From there and then that uh trust application usually happens that one after normal app is installed, it may come with a long ways together. Maybe bundled, but step is just yet I have normal app happens. Names start to install The Trusted application so that in step one we have an enp two-step. We just make it after a then a user can already download the app and install and at that time, if you need tats already supplied to time right, so that timeline here just to make is a installer sequence.

D

This way it's a it'd be more natural than the origin background, so you can see difference already step one three four here, then two, a two B is a it's. A three is in mid of two and two B. So that's the change instead of the Three Can Happen must happen after B uh it's about right, but you know this one's also, um maybe more natural foreign next slide.

D

ah This kind of major change, so the current paragraph says a in section 6.1 but rule of a TV Brokers. The first line says a cheaper broker abstracts the imaginative change after makes change, uh Ben and Roman both the commented. Well, it's a rule Minister for defense email. What that means program. What does object mean? So we uh David referred to this paragraph So.

D

We just remove word app track to explain it in plain language, so we just said tip broker interacts now, so just what what an abstract means, there's really explaining intact with cheap agent inside T and the job is relay and message between tip agent attack. The remaining follows right. I would say this: uh no um material changes somewhere more a little more explanations and what the abstract means. It's really just a defined uh flow and it's a role and next slide. Please.

A

Hey man you're running over, so we'll give you one.

D

A

Command, if you can wrap up okay.

D

C

Yeah and skip the ones which you think we can review it offline right. Can you focus on the slides, which you think the working group needs to hear right now skip to the slide, which you think is a very critical comment.

D

Hello, someone speak.

C

I was saying, uh can you skip? Can you move to the slides which you think are quite critical? Yes,.

D

Yes, next slide just roll it and next slide.

D

uh Next slide, because those are all the you can share uh sliding next slide, because others are just a minor update, um so class, okay or just a class of devices. We add a reference to the middle. One means the class of the class of devices refer to it in adaptation. Next slide, I want to go to the next slide.

D

Next slide yeah this one's uh already covered this one I just said we did a made update, inclusive language. This is from multiple production, Lars and romance, and we change many in the middle to manipulate in the middle okay. So I just said that one is a maybe a little new terminology and a new, but uh they will look up uh in some different uh specs. It's like a manipulator in Middle. It's a well accepted one retain the same uh acronym mitn right so still started with f, uh that's about it.

D

Yeah next slide of a niche I think we'll skip it. So you can go to the next slide, but it's at the top yeah. This is a minor. So it's just for reference purpose. That's all I have thank you.

C

E

F

A

Go ahead, Brendan.

G

I I just had a quick comment on that last one. The most common terminology, I've seen, has been on path attacker.

D

B

Is it? Okay? Yes, um yes, so this is and I'm going to talk about the hackathon and next next, please.

B

B

Hackathon, unfortunately, I'm only wrote something: I was able to pick up, and many of the early pages is a more about the clarification we had to talk and doing the hackathon. Yes, next page, please and yeah. These are pictures and we're running out of time. So next, please yes, um wait! Yes, I I have some of the points um planned for the hackathon and we're going through of them in the from the next slides yeah.

B

Next page, please, yes, um yes, um this was uh something we did talk at the iet114 and heavily after the one one. Four. We wanted to have a way whether 10 have to read contents of the attestation payload with without opening or verifying the signature, and we have to revisit this again um uh for this.

B

This hackathon- and this is the detail of the conclusion, so we do not have to revisit again so we, um the time, will read attestation payload format and then, if the matches with the uh attestation result string described in the slide, then Tamil have interest and going to open it and process it other than that we'll pass the contents of the attestation payroll to the um verifier um it. Yes, yes, and next page, please.

B

um There's a hand.

A

Muhammad Muhammad you're in the Q.

H

Yeah, so do you hear me.

B

H

Okay, so so what exactly do you mean by if you go back to last slide, please? uh What exactly do you mean by payload? It's an undefined term. I, don't see it anywhere.

H

Does it mean the in the in the context of t s c x? Does it mean let's say the code, or does it mean the report or what exactly does it mean because.

B

You go back to the uh yes.

B

um It's a b string, so it's it's a binary. um It depends on the implementation if it's Opti or sgx or yes, um yes,.

H

Yeah for scx, what exactly would it mean.

B

H

So so for sgx software guard Extensions by Intel. What exactly would it mean.

H

A

Dave is coming up to the mick to help sure.

I

This is Dave Taylor, um the word payload, just by itself, just means uh in the middle of the slide. There you see the two lines of the question mark in front of them. It's the name of the field in the teeth message um that doesn't answer Muhammad's question, but that's what that the first question was: what does payload mean? Okay and so uh there's two Fields right. There's the payload, that's a byte string, you know a bike blob and then there's a text.

I

It's a format that tells you what the format of that fight Club is. So the second question is well what, if you're using sgx? Okay, if you were using sgx, this document doesn't tell you the answer to that. But what does say is that if you were using say an sgx quote, then you would Define a text value for attestation, payload format. That says this is an sgx quote and then you'd put the quote into the b-ster. This document doesn't tell you what the text values are and the B Star values are.

I

It provides a way for people to register them, and so, if you are using sgx, you could do that and then use these two values. Where text would be, you know, sgx quote or whatever the registered value is, and then you put the quote into the bistro field in the attestation payload.

F

Hi, this is Hannis um I, wonder whether we should use this newly sort of published draft in the rat smoking group on the message wrapper, which allows you to kind of do exactly what um what is described on the slide to wrap um these rats conceptual messages which evidence and attestation result uh certainly are so maybe worthwhile to look at that I would send a it just occurred to me now, as as you are presenting it, it uh missed it previously.

F

Which was for what? It was also discussed uh with net and in the context of sgx in the in the CCC.

B

B

And yes, after the hackathon yesterday and the day before yesterday, we talked with the um Ken and isobasan, and probably the the implementer of the time will be reading the payload, the format, whether the Tam is interested for the really the opening signature of the of payload or not, probably, is the right way of the interpretation of this um issue.

B

Yes, okay and and next page- please, yes, um yeah I mean I'm, not I have I need to go forward, so this is uh originated for a very long time from IIT 105 and it's about how um started the implementation of the background check model. So um what will happen in the combination of passport model and- uh and we did discuss in the IIT 114- that um if we could have a passport background check, model and passport model combination, implementation in the tip, then we will uh we. We have.

B

We had to add another uh message to send the attestation result to the radaring party. Then we we decided to put it in the update message and we did add a format for the putting the payload in that update message. But we didn't really talk about the in the draft. So yeah this is the this um explanation again and we might able we might it's a based on why or somebody else might have had a little bit of description in the um draft later, with the pull request.

B

Okay and next page- please, yes, yes, yeah! This was. This is also something um we've been talking between the 114 and 115.. We decided not to use Seaboard Tech on the uh tip message and uh and but how about the suit envelope. Initially, the draft was using tagged suit envelope and the conclusion is not to use this suit envelope and yes, yeah. Okay, let's go to the next page, and this is what almost the date was doing in his implementation.

B

So, at the last it we decided to have um what uh decided what is will be Monday to Monday three in um authentication, algorithm, we're going to use and es256 and eddsa was decided, and we just- uh and that was a little bit uh related with the query- requests having needed to have multiple um signature on it, and we decided to use course assign which supports the multiple signature instead of course, assign one, which was which only uh have one signature on it and yes and then we need to, uh and many of the people is relying on the girlfriend um Lawrence implementation and yes, we're just going to proceed uh supporting it next page.

B

Please- and this is fixed and see, details, syntax error, which I was talking a little bit in 104. and we did finally fix it. It took me a little about three or three days and had to talk with the Brandon and many people in the Carson and to tackle it and made and uh and also I wrote the description how to go through to check the tip protocol, cddl syntax check on the readme. So, probably it's okay now, but but it, however, it does depends on the suit uh suit.

B

Message has need to be also uh requires City to syntax error error, so probably in the future, where you will go split. The make file command just going through the syntax check on the tip message itself or uh with, or only with the suit uh related message- foreign. Yes, next page, please!

B

Yes, um yes, this is go back for me, it's more uh going back from otrp age when the tip was using. um It had a feature to delete the trusted component and we decided to have a way to delete with using suit manifest for The Trusted component.

B

Then what do you how to specify the the target of the Twisted component? What kind of ID we use and and the suitizes the benefit of the suit digest? Is it's a hash value inside? So if it's any of the value, it changes with the in the binary and then it's easy to spot spot it. But we yes at the conclusion we're going to use suit component identifier, identifier, okay and the next page.

B

Please and there's many implementations are going on the table, so miyaza song came attended the eitf for the first time, so he was implementing passport model on the protocol, which is very beneficial. My implementation not doing that and any other people so and it's uh yes and it has a so four sequences. He didn't seems like to finish all the fourth sequence, but um it's uh it's making a progress for making the draft complete and it can is uh yes, he was he. He was I, think it was yesterday or the day yesterday.

B

He made a huge among us a lot of uh the pull requests.

B

um Yes and and.

B

Yeah yeah, yes and the isobasa was yes, adding remote attestation and was also clarifying many of the features of the on the tip combination with um rat's activity, yes and uh yeah. The summary implementation, many of the implementations link is here and the solved topics. It's not only these because it's already something I was able to pick up and so far I was I. I was uh known well by watching the GitHub, with five pull requests and updating the draft, and also a new issue was uh yeah filed like three I think yeah.

B

B

And this next page and next page there's two more additional page for the who wants to go through um by yourself. um The next page is probably the order links.

B

Yes, um any question: please.

A

That was actually great progress.

B

That's good. Thank you.

I

All right, a couple of these slides will overlap with uh Akira, so we'll try to go through those uh extra fast and leave the time for the other ones. Here, all right, so T protocol, a bunch of co-authors next slide.

I

All right so there's three sections: General things, things specific to suit and things specific to rats. So here's the first section, which is the shortest one, General deep protocol issues all right.

I

So there was a discussion in the past or an issue was which tape messages are protected with which Cipher, Suites, okay and so uh after the first exchange. It's really easy because once you've done negotiation, you use the negotiated one right. But how do you do the negotiation? That's where this one comes up. Okay, we do specify the same. Cipher Suite is used in both directions.

I

Okay, so one the one that you're using for signing is the one that you're using for for checking and so on. um We don't preclude. If you ever needed to be um different in the two directions, then an extension could do that. Okay, um but we didn't need to do that now in the base. Spec S, as um Akira mentioned The Courier request, which is the very first request right since you don't know what the other side has, then you need to try both.

I

um So the Tam must support both algorithms, both es-256 and edgsa, and the device gets to pick one okay. It can choose either one of them, but it has to do one of those two okay. So the first message that comes from the Tam has to try both because it doesn't necessarily know what the device has, and so this is where it switched to say cos a sign which allows you to sign the same message with both algorithms. Okay.

I

There was four other Alternatives that were considered and discussed, but that was the one that um out of the people that were commenting on it before multiple people, like that one, the best, and so that's the one we put into the spec and then started implementing and the only implementation issue we saw as Shakira mentioned, was that t cosay doesn't yet support the ability to do eddsa with uh cause a sine. It only has es256 and and so on, so that, but that will be coming.

I

We said we're not going to change the spec waiting for a single implementation where the implementation is in progress, so we'll just do that and encourage implementations. Okay and also clarify this is before that the first response from the a from the device itself uses the same uh mechanism as as later messages before the spec was ambiguous as to is it actually signed or not, and now it says it is it's.

I

The only weird Corner case is if for some reason the uh Tam sends a message and doesn't put the mandatory ones in its list of signatures.

I

um Then, of course the the device is going to say well, I, don't support either of those I support the mandatory one, and so we allow this case. That says, if you end up having to send an error, unsupported Cipher Suites, which would typically happen if the T, if the Tam supports the mandatory ones, but then it really wants to upgrade to a much later one right that the third one, the new, the the new and fancy thing- and it says I only support that one. Can you support that one?

I

It says no I support this one, and so that's for that corner case. It's not disallowed. So it's it's just there. Okay, next, okay, unrecognized heat messages. Okay, so let's say you have something that uh sends a teep message, but the message number isn't one of the regular six query request corresponds update error success. What if it's an other random number? What do you do? Okay or anything else it does that violates the spec. What do you do if you violate the spec? Well, there's the iup uh document.

I

That argues that um anything that says you just drop invalid messages that that's actually harmful because it lets the bugs propagate and stay in the wild, and instead you should really reply with an error so to put the pressure on the people that are doing their own thing. The implementation is doing the right thing and so uh two sides. The first part, is what happens when a TP agent includes an illegal message, receives an illegal message from a town.

I

Well, we've got an error message, so we just change it say you said an error in that case Okay. So that's what the that's, what the device does if the Tams has some that some something that's like a bug: okay, next slide. So what do you do if the tip agents in something? That's bad, so what does the Tam do right? Because the The Tam everything is initiated from The Tam and then responded to by the agent right, and so the Tam doesn't have a I'm going to send you an error right.

I

It can send a query request or an update, um but that's pretty much it, and so previously it said it just drops the message: if it's not valid uh and you can't send an error message, uh but the Tam can actually update software. So if there's a bug in the type agent, the Tim can fix that by setting a fixed version right and so what the document says now or the proposed text ad, because this is not fixed in the last one. That's posted. uh This text is I.

I

Think in the GitHub repository pull request says it may also do additional implementation, specific actions such as logging, the results like if you don't yet have a newer version to install um or attempting to update the tpage into a version that does not send invalid messages. Okay, so my login says: please get a new implementation whatever. If you've got one, then you initiate the update to go and fix the thing right now to stop sending you the bad messages.

I

Okay, so that's that issue all right, there's a bunch of editorial things that I'm not going to go through here, because I believe the person that brought them up so Michael, Richardson, Thomas, fasady and so on. I think have already act all the responses and there tend to be editorial. So if you want to talk about one of those ask me at the end, otherwise I'm going to go on all right.

I

So let's talk about things that are specific to suit okay and so now, I'm going to call talk, go through a couple of issues about the relationship to suit. Yes,.

A

E

Oh yeah questions or somebody. Yes, please uh Mike, hello, Michael um I, just want to say ticosi does support eddsa since September.

I

uh Edgsa, yes, and in fact during the hackathon I, was actually using edgsa. Obviously, um but I can't use it with cos, I sign and so.

E

I

Sign is currently only in the dead branch and eddsa is currently only in the main branch where it actually exists. No branch that you can use eddsa with cos a sign.

E

Yes, I know that he was going to add so.

I

Yeah we actually did get I I did get EDSA working during the hackathon I just couldn't use it with the query request message: all the other messages, after that eddsa was working. Great I actually did. That was one of my main tests on Saturday was to get EDSA working with all of their messages and my test passing, and they all worked great. So thank you for the EDSA support in t Jose, all right use of suit next slide.

I

Okay, so uh for those of you that were in the uh suit meeting and our hour and a half ago, uh Brennan actually talked about this one, and so this is the more details as to where it came from so Ian uh teep.

I

You want to be able to uninstall things that were previously installed, so I've got some trusted applications that I want to uninstall, and so uh the unneeded Manifest list is what does that and whether it's a suit digest or not a cure mentioned this I'll come to this on the later slide, so ignore that for the point, but you can specify here's some manifests to clean up okay, and so this works as long as the installation. Manifest already includes the unlinked directives right.

I

Otherwise, you have to go off and get a newer version of the Manifest that has the unlinked directives, okay, and so what if that hasn't happened yet? Or do you pre-cache it? So there's all these weird things: it says what, if I don't have a newer version?

I

um I can't create it myself because that was created by the software developer, that created that manifest, maybe okay, and so, although there could be ways to do that, this is the most natural way to do. It is to say to encourage the Manifest to install stuff to also have the uninstall commands, so that I can just reference that same manifest and say that manifest that you installed before just go and uh follow the unlinked directives and clean it up, because you've already got it.

I

Okay, this also solves the local admin case that says: okay, I put something down on a particular machine and and now not with the teak protocol. But if an admin walks up to the machine, let's say he can get to a command line or some other variation of of remote.

I

You know um remote login um and then you can initiate a local uninstall without using the T protocol, because the Manifest is already there right, so 10 tends to be most useful there, and so we put this into suit trust domains and that's what Brendan presented in the T in this you working group earlier. So this just says this takes a dependency on that, and this is this is in draft 11.. So next slide ask you some questions.

I

Okay, Akira mentioned this one. We stuck with the suit envelope, untagged I'm not going to go through this one, because Akira already did unless there's questions. Oh, but the one question: that's don't go on the next slide because there's a follow-up question on here, which is um as part of that it came up. It says: well the only case that you might want. The thought was the only case you might want to tag. There is what, if you had other C board-based manifest formats you ever want to allow in the future.

I

Okay- and you want to do that without waiting for an extension and still use the Manifest list to reuse the Manifest list, and the discussion was to uh not do that because you can always do it in an extension. But if you're going to eventually allow other manifest formats, then you might want to do things that aren't just seabor.

I

So, for example, if you wanted to be able to pass an MSI, your APK or something like that as your manifest right and then you'd want something that wasn't c word based, and so you would need something else anyway, and so the the suit envelope tag doesn't help you with those right, and so we said, that's that's why we're not using suit manifest tags and so for other manifest formats, we'll leave that to an extension um and then that could allow you to use other manifest formats.

I

If you wanted to use it with, you know apks and sis whatever else so, but not in the base document. Okay! So next, so that's that's the proposal here. If anybody has an immediate demand, speak up, but that's the resolution right now is to say uh the things that people need right now is in the base. Spec. Anything else is an extension document uh by the way Sue took the same approach or the suit manifest, so that okay.

I

um All right the suit digest. Okay, so I said I was going to come back to this one suit, digest or suit component identifier is where we ended up, but cure did mention this, and uh the more details there is that we ran into in the hackathon was the suit digest, if you have a case, say a device with multiple tees?

I

Okay, so let's say you have a te in a network interface card or something like that, and you got two cards or you have two different processors or you have two different areas in the same processor and you want to take the same component and install it in multiple places like I want in this line card and in that line card you can't do that by just saying: delete the one with this manifest with this that manifest uh hash.

I

Okay, because it's in multiple places right, so you need the more granularity and that's what the suit component identifier gives. You is it's a path that says which place it is, and so now you can be more granular and say: I want to delete the one in this location instead of just the one with this hash, which which is not necessarily just one. So that's why we did that and so during the hackathon. This is not in the draft.

I

Yet this is one of the things we ran into an implementation, and so everybody around the table that had implementations there. uh We kind of brought this up and unless there's any objections, then this is what would appear in the next version of the document to address that.

I

Okay and then the last part here is um uh deletion by a component. Identifier requires that you have a component identifier for every manifest, and this brought up the discussion that in suit we only had component IDs and Brennan mentioned this. In the suit meeting. uh We only had component IDs when you are a manifest. It depends on another manifest and the other one has a component ID, but the root one doesn't which is fine if you're a constrained device, but if you're a device with a bunch of trusted applications installed.

I

Every trusted application is its own root manifest, and there was no component identifier for that. Okay, and so that's what Brandon proposed that we added into trust domains. For this case, it was I, think the word oversight uh came up not by intent, and so this is the what motivated the discussion that Brennan had in the Sue working group before so again. Another case for the teat protocol actually requires this in order to do install and uninstall multiple trusted applications all right all right this one. We also did mention briefly and you'll notice.

I

My slide that I already had prepared points out what somebody else said that the mic and the suit manifest and the suit working group. So the T protocol does not do encryption at the message layer. Okay, it does encryption at the payload layer. So, for example, you can pass an encrypted payload in it in a unencrypted message.

I

Okay, it only does signing, and so uh the current teep protocol spec says nothing about the privacy of suit reports um and by the way, neither does superpowers today, and so that means that um we don't actually say anything and we need to say something someplace and so teep isn't the only place reports are likely to be used.

I

So this is somebody else made this point in the suit working group meeting, and so this says, since suit reports can be used in other mechanisms, then suit reports is the right place to specify how to encrypt and protect suit reports. Okay, and so the proposal is to um mention it in security considerations and point to the suit reports for the actual details.

I

Okay uh and I see maybe some head shaking. If you think that that's not right come to if I said it wrong, um Russ or Brennan come in and weigh in so.

A

I'll, forgive that you're not in the queue yeah.

J

That's not what I heard okay.

I

But can you summarize okay suit working group chair at.

J

The mic, so so uh what I heard was gee, there's lots of places where we want these uh plain and that when they're put inside, for example, an eat it'll be the eat profile that specifies how uh to encrypt it. But the the security considerations need to say what aspects such a rapper needs is. What I heard.

I

Okay, then, let's have that discussion now, since we kind of deferred people here, um if you are storing it in a file for transmission via sneakernet, whose job is it to true that I would say, whoever writes it to a file. You need a file format, and so that's why you might need to say an arbitrary way of seeing a suit report uh can be encrypted right.

J

I think that's probably the.

I

Case and that's my argument for why I should be in the suit reports document.

A

I

I mean that's why it's Brendan's job in that mine.

G

To clarify you're asking for a security consideration in the suit reports document that says, if there's sensitive information in here, you should probably encrypt it and.

C

I

G

Sure I understand what you're asking for, because that's what it sounds like to me that.

I

Would be minimum I think there's an interesting question which I do not know the answer to right now, which is: um does it make sense to say more details about that in terms of uh so let's, let's reference your MTI document, if you're going to encrypt it whose job is to decide uh constraints on the algorithm, should you say you should encrypt it with one of the things in the MPI document.

G

So from a practical perspective, and remembering that that MTI document is explicitly for constrained, node firmware, update and no other uses of suit, yeah that it's already taken care of, because your device only has that algorithm anyway. Fair.

I

Yep, uh so do I. Take it, as your view is that uh suit report should say that you should do it, but not specify algorithm details and leave that to you. Whatever the container is whether it's a eat profile or somebody doing a file or whatever else gets inside. That.

G

Yeah because I I don't think it makes sense for me to specify in suit report, for example, that you should put it in a zip file and make sure there's a password on it. Okay, all right that doesn't make sense, but maybe there's a use case where you need to do that.

I

Okay, so if you're gonna, you know cozy wrap it an encrypted thing that wouldn't be in the suit document right.

G

And because that would preclude you from putting it in a zip file and writing a password on it. Okay,.

I

Anybody else that that sounds like where we're going so anybody else have a view on that. One: okay, if not we'll, take that as the the proposed consensus. Okay. Thank you.

A

I'm sorry I was checking on the notes to make sure we're capturing.

I

That yeah I don't see anybody else on the on the queue all right. Thank you, Russ and Brennan. Next, all right, that's the end of my discussion of suit, although suit does come up on one later slide, so if you're from don't lose, don't leave the room which has to do with the relationship you're in suit and rats and teeth.

I

So now we'll get into the details of attestation and the relationship to eat tokens and the rat's working group so, and these I think this is the longest section of slides, so you'll have to track my time and tell me how I'm doing so. Okay eat tokens. Okay, we just had a discussion about suit. Reports can contain sensitive information by the way eat. Tokens can contain sensitive information.

I

What draft 11 said um is uh it should use encryption as discussed in eat? Okay, as opposed to some other type of encryption right. uh The problem is the eat profile. Section in uh draft 11 has a bug in it where it says under cosine and Jose protection, in this case just cosay protection. That's the field name out of the out of the each specification. It says you got to have a field that says this. We only use cosay, um it says, see the cipher Suite section.

I

The problem is the safer Suite section is the one for cheap messages and T messages are not encrypted, and so right now you can't file that the the cipher Suite actually is is false, because this would tell you no encryption. You got to do encryption right. So that's the bug. Okay, and so the question is when you're sending. In each token that has sensitive information, and you should use encryption as discussed in eat, then what Cipher Suite? Should you use? Okay um and you know, for example, do you sign and then encrypt eat?

I

Do you encrypt it and then sign probably sign and then encrypt, um but which Cipher suite for encryption? Do we specify in the eat profile? Okay, because we don't specify for the T message we specify for the eat profile. We got to specify something there, and so this is where I mentioned suit. Here is you could make an argument that a good Cipher Suite to use is the one that you're already implementing for your suit reports?

I

If you care about sensitive information in both eat and Sue reports- okay, it sure would be nice to do have these same things that are mandatory to implement in constrained devices. Okay, so that's a good argument there.

I

um The a possible argument on the other side is that the um uh destination of the suit report and the destination of the eat are different entities who might have different requirements right. One goes to a um uh a verifier and one might go to uh The Tam, who might be processing the suit report, and so maybe there's cases we want them to be different, but I guess right now, my preference would be to recommend them be the same and leave it to extensions to.

I

If you ever had a case, you wanted to be different and if they're the same, that means that um we still need to pick something. Okay, if you go back to the discussion that Brennan and Russ and I were just having whatever the encryption mechanism is for suit.

I

Reports is something that the suit report itself document would not say we do that in the eat profile, and we would also say the same thing in uh for for suit reports, as well as uh the eats themselves, because the point that I made the suit working group is it's not just the suit report and the eat. There's a bunch of other claims in the eat. That's not right, since we want some generic statement, some generic algorithm in crypto. So far, we've only talked about in this working group.

I

Signature, albums we've talked about eddsa and es-256. We've not talked about the crypto algorithms or sorry, the the encryption, algorithms and so um I guess I would like uh maybe Brendan's opinion uh since Brandon had the mandatory to implement document and suit for constrained devices. Should we just take the cipher Suites or some portion of Cipher Suites there as the default one for this working group in the eat profile?

I

Or is there any reason to use different ones than what you put into the uh uh and again we're talking about those encryption? Algorithms in the MTI document in suit I.

G

Gather that some of the implementers already have a hard requirement in tip for using RSA in signature use cases. That being the case, I would be inclined to ask them what they require, because those are not in the suit MTI draft.

I

Okay, anybody here have an opinion, otherwise, we'll ask the question on the list: anybody here have an opinion on uh encryption, algorithms for use in encrypting suit reports and or eat tokens.

I

G

Not we'll just ask it on the list. Sorry Brendan Warren back at the mic, maybe I misunderstood the question. This isn't about key exchange at all. Is that you're just talking about the symmetric encryption? Okay? My apologies um right. There's been a massive discussion going on on this and given the kind of environment that you're in I strikes me that you do not need to deal with out of order arrival of uh data correct.

G

You do not need to deal with a situation where you haven't got enough space to store the ciphertext instead of the plain text correct.

I

uh Because here it's the sender, it's the one, that's likely to be constrained, not the receiver. So.

G

This should not be an issue for you and on that basis, I wouldn't try to use any of the constrained stuff. You probably want to use one of the aeads just because it provides less room for error.

I

Yeah that there might be uh requirements that says the Gen, the the encrypter side needs to be as as small as possible in terms of the implementation of space and so on. But the decryption side is probably unconstrained. Yeah.

G

So if you can afford aesj, GCM or AES CCM, then okay, that's the direction you want to go. Okay, thank you for the recommendation.

I

All right, plus one okay plus two, that's the the harness also thumbs up. Okay, uh next slide.

I

Okay, um Thomas fasady asked raise this one uh in draft 11.

I

It said that in the eat profile, all claims were listed as optional, and he observed that that's probably wrong, um and so uh there's an open pull request here, ready to be merged. If there's consensus that has this. That has um one two three, those five. So this there was six claims already talked about in the document. Okay and these match to what the architecture document says.

I

That uh Tam would need to know in order to do remediation right, and so those are the five and then the fifth one is just for freshness, so the five ones. It's actually information that they need to make a decision as to what binaries are appropriate on the device and whether they're up to date and so on is those five right, a unique identifier of the device- and you can identifier of the OEM or Hardware vendor what the model the version is and the manifests that are already installed on the device.

I

That's the list, okay, so the proposal is to take all five of them and then make those be mandatory instead of optional and then the sixth one is the nonce and that one will be mandatory. If you're using the nonce freshness scheme and if you're using the timestamp freshness scheme, then the timestamp is mandatory instead, okay- and so that's the proposed resolution uh to that one so uh because I think the only way to implement a tam is to have all the information. So okay, It's News comments, next slide.

I

Okay, so the each spec says this. So this is one that we talked about at the hackathon and we talked about it between the suit rats and people that were uh at the tables and things uh the eat. Spec says a suit: manifest can be used as a manifest and then the eat.

I

Spec has Fields there for a content type, which is a co-op content format and a con, and then a the body which is in this case like a Json or Seaboard blob, and so he says well exactly how do I put a suit manifest in there? Okay, um if I'm going to use Seaboard which seaboar production is it okay? Is it the suit envelope or is it a suit reference or what and so uh between Brendan and me and uh I think Lawrence.

I

uh He said well, the proposal is to say what you put in here is a suit reference.

I

Okay, you know it's the the ID and the URL from where you can get it and so on, but not not the whole thing right, and so that means that uh someplace we would need to write this down and get a co-op content format for the suit reference. Okay, so that is. The proposal is to get a new value allocated for Co-Op content format.

I

That means that specifically, a suit reference object um and then write down, and where would we write that down probably in draft ietf suit reports, which is what defines the student, the suit reference cddl?

I

Okay I saw a couple nods, so okay, so that means that's work for Brendan. That I would uh in in the suit reports document that we will then reference in this document. So.

I

F

I

Okay, next, okay, uh we did update this goes back to the the the spec used to have a very old uh sample eat token that needed to be updated with the latest claims and stuff as they appear and eat, and so this has been updated now, and so this fills in what we just talked about here and, of course, since there isn't a co-op content format, yet it temporarily has 60 app, which is application seaboor, with a to be replaced.

I

You dude that says as soon as they get a value change to 60 to be whatever the new one is right, but it means you could actually code this right now and use it in the meantime in in hackathon tests and stuff, and so and you can see- here's an example suit manifest, which has a sample URI and the digest and so on, and so this is just in the pull request, which, unless is the objections, will merge the pull request and that'll be what's in the dashed? Well yeah!

I

Next, okay, um this is the intro to the next one. This is not the open issue, but as a reminder uh way back when in 105 we talked about how you could use this in the following orientation, where the Tam is kind of in the middle, um where, uh when a tester wants to get attestation results that can present to some other relying party, they do so by sending it through the Tam, as if the Tam was a verifier.

I

So it's like you have chained verifiers in each case, so you send it to who you think is the verifier, which is after the Tam, the tan sends it on another. Verifier gets back the optimization result. If it's a failure, The Tam kicks off remediation and starts doing updates as necessary. It would say success in their hand that passes it back to the tester, which can then present it okay. So that's the example flow here the example composition.

I

You don't have to do it this way, but this would be one way that might be popular, okay and so way back in I in the earlier ITF we said. So what message is it that passes the attestation result downward from The Tam to the tee and in iitf 114? We said that was the T update message where we updated it just before 114 to have that as the answer? Okay? So that's the pre. You got to understand this to understand the next slide. Okay, so now we've got the context next slide.

I

Okay, so the discussion we had at the hackathon is out of the teep profile or the eat. Profiles for ETC station results. Okay, there's two profiles that have been defined so far: one is the one: that's the keep profile in the teep document, that's for use by consumption by The, Tam attestation results is going to be consumed by The Tam. The other one is ar4si is the acronym for the draft and the in the rats working group and that one is designed for other relying parties which was that other box in the slide.

I

So the attestation results line that comes down there's one profile for the thing that comes to The Tam and a different profile for the things that comes to their lying party. So, what's the relationship between those two things? Okay, this is what we had the discussion with hackathon about, uh and it turned out that those two things could even be encoded differently because it is say both Json and C, bar, whichever one that you want, and so it could be that the Tam requires it in seabor and the other lying party requires it in Json.

I

uh So that means and similar your freshness mechanisms might be different. One might be using time stamps for freshness the other. One only supports nonsense, refreshness, okay, so it means you might have disjoint requirements here, and so does that mean that you need a to like encapsulate them and you did a media type for all the combinations of A and B and things, and so that just seemed um problematic, and so there was uh five options we discussed the first three of them have all those above issues, and so we kind of included.

I

Maybe that's not the right way to go, even though that's kind of what the draft previously would have implied, um but we didn't like any of those first, three um actually there's downsides to all five of these and that's why there's not a proposed one here. um I might have my own preference on here. So option number four is to say this one actually requires, uh since we don't say anything about the protocol between the Tam and the verifier okay, and neither does rats by the way right you can use whatever protocol that you want.

I

It just has so here's some message formats, but you got to put them in some protocol. You know it could be a HTTP rest API or whatever this one does have an option. Four has a constraint on that protocol, which says, when I'm going to have send off the evidence and I'm going to say hey, please give me attestation results in the form of you, know, seabor or give me it in here's. The profile I want the Deep profile or whatever is not number four in that request.

I

You'd say: I need it back in two different formats. Please give me two blobs: okay, not just one okay, so I can't just do like a regular, accept header right. It's probably constraining the protocol. I need it in this one and in this one one request two blobs in the response: okay, that's what number four is and then I can get it back.

I

One is opaque to The Tam and you can just pass it on and one is consumed by The, Tam, okay, and so that one is like having two parallel accept headers and two separate responses, one that you parse and one that you just pass on on that one's kind of weird. But you could do it and it's the fewest number of messages, maybe, um and but it does work with all the different previous constraints.

I

Option number five is to say well this flow that puts the Tam in the middle. Well, just don't do that instead make the tester go all the way around to get the air for our size. This line that comes here ar4si would not actually come through the dam, nor with the evidence the evidence would come to The Tam in a separate evidence would come to the verifier and each of them would respond separately. Okay, meaning evidence comes to the town. This one comes back here.

I

Other evidence comes all the way around the verifier and comes all the way around back to the tester or the other, relying party, depending where they're talking about uh background check or passport model. Okay, so that one means double the messages from the uh a test or the other relying party I, say or because it depends on background check versus passport model. Both cases are there, but they collapse into this, and so, if that was a constrained device, that means hey two messages: perhaps more power consumed and so on.

I

So that's the disadvantage of number five is more a little bit more complexity, because you can't hide all the complexity behind a tam if you have a tiny constrained device. Okay, so those are the five things that we know of right now.

I

um Anybody have an opinion on uh which, if there are some of those they would like to vote off of the island or they think would be the most appropriate for their favorite use case Okay.

I

um Otherwise, um since number four actually constrains the protocol um somewhere between four and five is my preference. Unless somebody has another magic idea and I would prefer to not try to do the you know, media type parameters allowing each combination, which all three of one two and three would have that problem. So.

I

So I kind of we kind of scratched our head during the hackathon said we'll bring it up here, see if anybody has any magic advice for us, so um otherwise the authors will try to figure out what to do in the next version of the draft. So, okay.

A

Pigling you're in the queue.

E

I

This one is the hardest issue, so if I get cut off on time or whatever, this is the one that I really wanted feedback on. So you got five minutes: okay, cool.

K

Hello, can you hear me.

I

K

I wonder if it's possible that the time is the verifier.

I

That there can be a case where you take the 10 roll and the verifier role, and you collapse them into the same node. Yes, that is possible uh and then uh option number four becomes much easier in that case right because there's no protocol between those it's your internal implementation.

K

Yeah because I think, if we use the time as a verifier and this model will be more simple to use, I think.

I

um We never want to force people to use the same uh Tam and verifier combined, but allow it yes force it. No, um and there are people doing verifiers that want verifier implementations to be usable with many different relying parties, including a tam for that matter.

I

um I think Verizon was one of the implementations, that's Thomas facades and folks. That was there at the hackathon. That's doing exactly that, and so we had some people at the table. They had the time implementation, some people at the table that had a verifier implementation and we wanted them to be able to interoperate without precluding the fact that you could combine them into the same implementation.

K

Okay, thank you.

B

Yeah between the um option, four four and five, probably I- will prefer four just because it's more easier to revise the current draft, but um not the technical um view, um but I have another question um with the some. The question I had in my hackathon is uh what what is the by reading the current draft? What is how to implement with the um other than um sgx or TDX, or something it's? It's really neat to yeah. Ask somebody who really knows the implementation or the history of the draft so um eat profile.

B

Explanation, probably we need to. um Yes, we make it more informative in the in the draft.

F

Yeah um I was actually wondering whether we need to cover post the the background check and the passport model um together like it would be possible to just stick with one specifically. If this one is more exotic or is like, um like nobody is forcing us to cover covered a whole um topological flows from the rights architecture,.

I

So here so far, the working group has been concentrating, what's shown here with the Tam and then same in the previous slide. Right is that the Tam is acting in the um uh background check mode right. In other words, it's the not the tester that talked to the verifier The Tam is a specific relying party for mediation, and so this is a background check picture here, but you saw at the in Curious hackathon report that one of the implementations was trying to do passport with this, so we actually do have our first implementation.

I

It's using not this picture right. It's using something, that's much closer to option. Five! Okay and accurate is not in here. The other implementation is using option five in turn, because it's using passport right. So this issue here the relationship tends to be more complicated in the background check model, which is actually more common, uh but not very ubiquitous right. So I think my opinion is especially after hearing the hackathon stuff, since we had both passport and background check, implementations at the table in the hackathon, as we probably need to accommodate both was my takeaway.

I

So uh before this hackathon I might have said, let's just use background check for the Tam, uh but now that we have an implementation that I'm now kind of convinced that that's not necessarily what everybody's going to do. So.

I

um The last thing that I will mention here is this uh bullet right here before we run out of time, is that um uh that Tam could, in theory send two different queries after the verifier right? If it just uses like a rest API with an accept, headers and stuff, it could send the evidence twice. Okay, but the only problem there is.

I

If it's using the nonce mechanism, it would need two different nonses or or the ability for the verifier the receiver to accept the same nonce twice right, and so it tends to have problems in the nonce mechanism. If you were using the timestamp freshness mechanism here, you could actually do that. Just fine, okay! So all right, if I still have time we'll do another slide. So yeah.

C

I

Was the last slide? No I got another okay, um the last one. This one is done in draft 11, so I just want to confirm. This is fine.

I

um I think uh I forget who raised this one, um the each profile is it when we talked about before that content format and we said how how it looked if it was an sgx code or whatever and there's the value that Akira showed.

I

That said, it was a an eat, profile, eat and say well, that's kind of a long string, um and so um what happens if, in the future, you rev that okay, because what it says right now is if your value you're going to send is equal to that string, you can he lied and they'll MIT, leaving that long string, because the absence implies it's that strings. The question was well as soon as you're rev. Doesn't that mean that you've lost encryption and the encryption?

I

It's not going to not encryption compression you're going to need that to be in all future messages anyway. So why bother with the Elijah now right and so I think it was Michael, Richards and Estes, and so what it says now is it says: well, whatever the absence means is defined by the T protocol version, which is a single integer out, so we're on the same header, okay, and so, if you ever wanted to rev it, then you can easily bump the Steep protocol version, which then specifies a different default.

I

So every time you can get a new default and you can always you know, omit the thing as long as you're sending the exact thing that that version says: okay, so provides a mechanism to rev, that's already in the spec, which is the the version number identifier and you say well: if we had deep version 2 or the keep version, a t extension or whatever would you say we'll put the value 2 in there and set the value 1 and then it has a different number in it, and you can easily do that.

I

So you can always get the and he said ACK on that being done. So it's just reporting that out next.

K

Hi hello: uh this is very brief. Full presentation of the tip use case for computational computing network. uh Next. To that side, please there are some issues: I collect from last meeting and I also upload in the tip for GitHub. So the first issue is a cloud scenario should be included included and the response is that we change the abstract, and this and the text is the documented- is a use case and extension of tip and could provide guidance for cloud computing, MSC and other scenarios to use computational Computing in network.

K

uh So next time please yeah he's a center issue. It's the security of competition container should be clarified, and since the CTC uh comes to a computer, Consortium have defined that the the conversation container so I changed. The I will follow the terminology definition and here's the example. If a CVS and pcpo maintains a container in your virtual machine, then this is a computer VM, rather a computational container.

K

So here is a fixed next slide. Please. uh This is the specified or refer to secure channel. In other document, I think I haven't found a definition of secure channel in ITF or maybe use the using attestation in transport layer and the data transporter layer. Security dropped as a secure Channel. Maybe I can use a loosen definition, for example, some some transformation from some transformation, a method that could protect the data in in transfer. Maybe this has haven't been determined and I. Think I will fix it in the next Edition.

K

uh So next slide please.

K

uh Your fourth issue is the typo and the form, the correction and I think I have fixed all the typos.

B

K

K

This is a operations type in 4.1, where a u8 and PDR bundled as a package, and the comment is that the network user could use a transfer encrypt package before a testation for efficiency and as a response I, we delete the encryption package under the decryption key, because if we already have a secure Channel, there is no need to encrypt the package and I also change the draft as that in the in the below step. Three is the time request, remote attention to the tip agent and the team agent is instance, evidence time.

K

uh Here's the point. The time works as verifying in red architecture and according to the conversation just before, if we don't force people to use, use the time as a verifier, maybe I need to lose this established another type so uh yeah, maybe I, need to loosen these steps and try to provide just the guidance in order to enforce people to use this network management management and orchestration Center as the verifier. So next slide please and here's a provision style, 4.

K

4.2, where PD is a separate package and the TA and the uar separated or Integrity. The comments here is that clarify, deploy and low load in this case. So in the step three, the network user will transfer your NTA to the computer Computing device via a TM, Time and Time Zone deploy these two applications in re and the T respectively and in sdx. The UA must be deployed. First then lets the UA to load the TA in the sdx.

K

So uh next slide, please it has Issue 7 here. The comment here is the time is not in the path of UA distribution, so we just fix the steps, as the network user deploys you and read, and how it deploys. I think it's out of scope of this document. So next slide. Please here here is a introduction.

K

Improvement I think it's uh I try to solve this issue by using multiple multiparty Computing and the factory Federated machine learning to explain these use cases because both MEC and the Federate ability will use T as a measure to protect the their private data. I'm not sure if I should add this text in the main body text or in the appendix and I think I will fix data in next Russian.

K

F

K

Please, okay, the specified data owner and in the document the data owner has been replaced by the network user because the network user possesses a personalization data and applications that need to be deployed on computer Force.

K

So next slide. Please.

K

Yeah, here's the losing deployment options, I think it relates to the issue: 5, 6 and 7, and next slide. Please- and here is the one question that the UA may be tempered and this may cause those attack or even the dorsal attack and I think that the UAE is defined as untrusted.

K

So the team architecture cannot make sure that the UA is secure and the trustworthness, so in some some meaning I think that the toss attack cannot be totally denied, but if we could create a screw Shadow between the T and the network user, all the time, for example, if we use course and to encode the network data, the server side of the t equal to discard this malicious Network flow as 2D broker. Since the team broker is a transport transparent, forwarding and is also not trusted.

K

So the network network flow filter may be not reliable to block Malaysia's traffic by the team broker. So next slide, please yeah and the scope of the document. I think the scope of the document should not only include Edge Computing scenario. A scope could be any computational Computing environment which need to be configured by Network I. Think that's the reporter.

E

A

Okay, so all these were updated on the last revision thing.

K

K

A

H

H

Yeah, so do you hear me.

K

Yeah I can't hear.

H

You okay, so so in one of the issues you mentioned, the definition that you use from CCC, confidential computer Consortium and.

E

H

Had analyzed some of their definitions and there is no scientific evidence for any of the definitions. Somebody has just put them around and there is no scientific kind of justification for these and I wonder. Why do you pick up these and uh so CCC is not a standardization body? I mean.

K

Because I think there's no uh standard definition about confidential uh commercial container and, from my perspective, uh in my opinion, I think that a container is confidential. It must be totally confidential. It cannot be a virtual machine. That is, we say. The word permission is a confidential, so the container is confidential. If we say a container is foundational, then only the container is confidential. Any components out of the container don't have to be translated that my personal opinion and I think this is a reasonable explanation of this competent container definition.

H

Yeah I mean that's: that's fine, that if you have your own perception but having CCC does not justify anything because I will put a link in the chat, so we analyze some of their definitions and there was no justification whatsoever for them.

H

So if you have your personal opinion, that's fine, but having the point was that having CCC definition or as a reference does not justify anything. Hey.

C

Guys, let's take it on the list yeah. This is a good discussion, but.

K

Let's continue on the rest, okay, okay,.

A

Yeah Muhammad: can you post the link and information that you were speaking on the list? Yes,.

H

Sure so I will put it in the so should I put it in the list or in the chat.

C

List please: okay,.

H

Sure sure I will send it in the list thanks. Okay,.

K

C

Thanks everyone for the session and I think we're making good progress. So hopefully we will see the Deep protocol drive for Advance very soon and we are hoping we will initiate early set directorate and iot directorate reviews on the T protocol.

A

So um Dave, once you have an updated protocol, the question will be: are we ready to do early reviews to get the working request home so we can take that up on the list. Akita.

A

Both protocol specification once you get the next revision, do you feel that it's mature enough that we can trigger an early review.

F

A

You don't have to answer now, but you know it's it's something that we can pick up on. The list appeared.

C

Yes, okay, let's take it offline and.

A

D