Add a meeting Rate this page

A

Hey folks, a line.

A

That's forest.

B

Yeah actually had some more pictures. I got a post.

B

Give everybody a couple of minutes here.

B

Tricia Hank: are you doing the sign e-content? No.

C

Unfortunately, not Friday and I decided to shelve that for next week. Oh okay.

B

That was our. Let me pull up with the agenda was then okay.

C

I know that's supposed to be the first thing, but next week works better first Thanks.

B

Who's ready who actually getting sleep this week.

B

Know how he does it? Oh.

B

Okay, you deleted this okay, that was our main topic.

B

Okay, in fact, I just mentioned, I was looking forward to seeing what you guys had I okay.

D

That discusses the comment you just left in the notary channel. If you like, I'm with.

A

The father.

D

Replies in that thread, but I haven't met it chance to really look at it. Oh.

B

There was a bunch of replies, I see all right, whoa, okay,.

B

Okay, why don't we do this.

B

Alright I'm a little calm, because I was really looking forward to saw anything so I'm trying to figure out, and it was actually not sure we're gonna have time for the other. What.

B

Alright, so what I had on the agenda was actually just pull it up here.

B

Oh.

B

I said you just moved to July 6 sorry I was seeing signing show up again, I was getting confused.

B

So what the the sketch that I'm talking about is the thing that we've been talking about for a while that might I can propose. We talk about that for marks, in addition just being on the agenda I the whole of goal of this one, and then we just put it here and I can share my screen as well.

B

Sure screen: oh there we go.

B

Okay,.

B

All right, so what I'll do a quick overview of it because the the goal? That's why I haven't done the PRT and it wasn't quite ready for it to for a larger discussion. So I'll write always ready for a larger discussion, but there are some details that people were asking that I wanted to cover.

B

First, the main thing that I think we were struggling with is: what is the high level scenario and an approach that we could go about it, because what we're seeing is we have a bunch of subject matter experts that really know their area really well and because this problem is so deep in so many areas that it's really hard for everybody to be an expert in everybody else's area. So it's trying to figure out.

B

How can we frame this so that the key management experts that really a focus that say on offline keys, like Neos and and some other folks, just yeah.

A

Here's here.

B

I can't say, look I, don't know well this other stuff by nowhere. I got a plug in. Let me focus on this and they're gonna surface up a set of questions and issues and requirements that we have to then adapt on another part, and likewise back and forth, so I was trying to figure out how to frame this. We've been referring to a sketch.

B

We've been referring to kind of buildings, if you think of like people that have really detailed designs on really cool bathrooms and so forth, like where does that fit in the house or other parts, so I was kind of thinking.

B

Just was thinking of the way Gaudi had done the Sagrada família and how he had basically was trying to come up with this new way of doing these amazing churches and the flying buttress design was so bulky and not you know what he was looking for, so what he did was he built a sketch uh that went out a sketch.

B

In this case, it was a model he started with sketches and then built this model which, if you haven't seen it, it's really amazing the way they use sand bags filled with birdshot that created this natural curve and he was able to prototype some things and figure out how it worked, which of course, then goes great. I got the structure, but where does all the stairwells and the plumbing and the lighting?

B

And there wasn't really that much lighting back then, but where does all of the infrastructure and the other pieces of a in this case a church fit into it? So it that sketch and very many models I was trying to find some that were open license. So I can put it here, but just do some sketches of the physical models that they've made to prototype designs and it's through that that they were able to come up with better approaches to facilitate communications.

B

So that's been what I've been trying to put that in place because I'm, not the expert in any particular area, but I can try to facilitate this conversation between folks that we can figure out. For instance, where does various pieces come in I'll pause there for a moment.

A

That's.

D

Yeah I think I mean this is fairly similar to the models we've had before. I guess. One thing, that's been a little harder in this community is usually we've when we work with other folks in lying, for instance, the automotive space like I I, I guarantee you that I know a hundred times more about cloud deployment scenarios that I knew about automotive when I first started there, and we agree that we need to kind of be working together and working together more closely and I.

D

Think you know have more of like a common goal about what we're trying to achieve, and then we working more closely together to get there and meet everyone's needs, because our goal here I feel like there's tension where it's almost like. There's groups building trying to build different models and that arguing, if that is not like God II, didn't go and then get a bunch of people to design different things and then like in the end, try to glom it together or try to try to do whatever I think we need to.

D

You, like all all decide that we're going to try to row the same boat for a while and see how that goes, because I think the kind of trying to pull different directions is what is what's causing this to be problematic.

B

I think well, anybody else.

B

Okay, so part of it I think is. This is why we were trying to get the scenarios down up front down down up front was that we could have that as the basis on what we're working on one of the things that I've kind of see us get. You know very focused on, and this is because that's probably your expertise in this area as Justin is the the update scenario, and you know the more. Obviously, the update framework has a lot to do with that, and one of more I was reading.

B

The more I was kind of seeing that's the pattern. That's consistent with what you've been representing one of I think what you're seeing is the that's a build. There is a build scenario where that is important, and we still you know. So it's not like it's not important. We do need to think about it, but when we think about doing deployments in the container space we talk about them in very immutable.

B

Fashions, like you, don't actually update a tag and ask a bunch of people to update that particular reference thing, because it creates it instable in stable environment, where you have multiple instances that could be out of sync with each other, whereas in the base image update, we want that because I want to know that I'm referencing version 14, you know something and when security updates come in, I get those because I'm referencing that thing but I didn't have to test them and you know verify them.

B

The other angle to that is the idea that there's this sole dependency, that's sold, but a very heavy weighted dependency on a public registry that all environments pull from and the thing we're seeing more and more as customers want private copies of there's even a public content, so that they have the ability to pull that public content in including the updates to a tag for space images, base, artifacts and then test those, and then they reference those in their private environment.

B

They have like a corporate set of artifacts that they reference that all teams would reference, even smaller teams, so I think it's a combination of those two high-level bits that would help to figure out where they fit in, because there's then we get into details of repos and from real clients and other stuff. That I think will flow out of that that we can figure out how to address some of those but they're going.

D

To route.

B

In those scenarios, maybe.

D

The second point is the easier one to talk about first, which is that like, if there's tough metadata on the public repo tough targets metadata, you can copy that tough targets metadata to your private repo and just use it there. It's it's not like it's not somehow associated with the repo. Your private repo will have its own snapshot file and we'll list that target this metadata on it. But there's no like there's nothing. Stopping you from taking targets metadata, which is you know just for everyone. Furgus metadata is the thing.

D

That's actually has the secure hatches it's actually signed by the developers that points to the images or whatever, so you can I think the second case you, you already need sort of have this with the tough design I.

B

Think the thing that I struggle with is we keep on. We talk about it as if this is an assumed fact and we and it's easier to use as opposed to I'm still struggling a little bit of. Is it really the we start with the end result, and we could use it here, but the question is: should we and where does, and how does it apply when I see things like the client initialization is out of scope that you like that concerns me the complexity of trying to pull these things together. You know.

D

We're.

B

Real quickly going down a rabbit hole again here, I mean I laid out. Think.

D

We're.

B

Starting with the place of you're, arguing that we should it's okay, we can use this and I'm saying still understand what is the purpose of it like? What problem does it solve.

D

All right, I mean we're. Gonna have kind of deja vu in this meeting all over again we're we're, welcome to go back through the scenarios and talk about the the problems to talk about. Why, when you have tag matching you the repository telling you what your tag latest matches is problematic, that you need sign metadata from the user to do that like fundamentally, if you want, we don't want the repository to be able to control what a tag points to here so and that to me is an important but like use case or attack case.

D

Even if it's common that people use tags differently, it's not always the case that they use latest. Sometimes they do. But in those cases that's it's important that and about you know that I, don't know half a dozen other reasons that we brought up related to all the problems with snapshot and everything else that we talked about. There's like a whole bunch of small, but in you know seemingly important little reasons that there, but the the case of copying metadata over I mean you brought up. Two cases use a copy metadata over.

D

You can literally just take and copy targets metadata over and stick it on the other repository on the private repository and that works just fine right. So that's there's you know and I. If you want me to talk in more detail about why that works or what happens I can, but that's that's sort of like that's a non-issue.

D

The the first point you brought up was saying: oh, this is for updates. This is whatever no TUF TUF does key management. It does like revocation of trust, it does all sorts of things.

D

Yes, in some cases, if you're doing, depending on how you do your trust on first use or what you do or why, then some of these properties are better or worse, just like in some cases, if your networks protected- and there really aren't any bad guys on it, then you know then, like TLS isn't helping you right, but hey you know like you, you still may use it, because it's it's considered helpful.

D

So, once again, I feel like we've, we've kind of gone backwards, like I felt we'd get you laid out two things that were quite constructive, that we could talk about and now it's kind of like well but yeah. Those two things maybe are solved, but let me move the goalposts and talk about the things that I think are a problem like tough, doesn't mandate a way to deal with how you do trust them first used. Well, we don't mandate it, but we support like the way in notary v1 does.

D

It is not the way that we recommended it be done and- and you know, isn't the way that I'm aware that any other group does does trust or for this it's still supported. We could do it, a notary, v2 and some people might in certain environments. But this isn't like you know this, isn't like the fact that tough allows you to pick a couple of options here, isn't necessarily mean that tough can't do this problem. It just means that there's there's multiple paths that different people have chosen, so I don't know like I.

D

Let me shut up for a bit and let others hopefully respond and weigh in I.

E

Don't.

C

Think they.

E

Did.

C

Oh thanks I think it could just be a mismatch of honestly just language and expectations really like I, think the way we designed tough now and we made like a radical change to it. Right like like, with design option 2 with the the Merkel tree snapshot metadata. We were fairly confident. It will work with all of the deployment scenarios.

C

I think what's not cleared to you guys is that that really is the case, especially with things like that seemed to pop up all the time like bootstrapping, rude metadata, which we think is a fairly simple problem, but maybe maybe this is just something we're not on this ending here, so I think I.

C

Think I think we just need a meeting to sit down and figure out this problem once and for all right like if we, if the thinking is that tough is not gonna solve the problems at all. But we need to know why and we we were fairly confident. We can fix the problems and we're also not trying to, at the same time, trying to forcefully shoehorn thought here and say.

C

This is the only thing that that that can possibly work, but we're fairly confident that any solution that that we end up designing would look fairly similar I, don't know that makes any sense, but.

B

No does I think this piece that I get so the piece that I'm struggling with is we start with that's the answer and let's, when it's easy to use as opposed to we don't the we don't see the updating of a tag being the primary concern, in fact, there's a design proposal that we've talked about that there's an immutable tag, option that says that you in.

A

The spec.

B

Like all the clouds have actually supported this option in various forms that you can lock a tag from being updated. Maybe that's something we should put into the spec. That says there is a standard way that a tag cannot be changed for one set of you know for the deployment scenarios, so I think that's the part that it it gets gets me uncomfortable is when we keep on talking about. That is the primary scenario and that's not the primary problem. Oh.

C

I think I see what you're saying yes, that that what that also wasn't clear to me until recently either. But yes, I've, come to understand that the latest thinking in the industry is that yeah tax tags should be. In fact you don't even want to pull things necessarily by tags anymore. You want to pull things directly by digest, at least in the scene at will. That is the thinking yeah.

B

And I, that's I'd actually suggest that the reason people go to digest is because tags don't have a way to be locked if we had. Oh because there's problems with digest as well being very long, not very you know, friendly being able to see in logs or in dashboards and there's no break glass scenario.

B

So if you have a tag and it's locked, then you can use it, but and if you have a reason to break glass and say I do need to update the tag you do have an option there, but I I would say that you know it is it's not a way of best practices, use digest it's an immutable workaround to the limitations of what's available so.

D

Who, who decides to lock a tag? A user right, like the person using the registry, decides to lock a tag correct? The.

B

Owner of the entity right.

D

Okay and then, who enforces locking a tag like? How would does that actually happen? It would be the registry that enforces it right, correct.

B

Right, the registry.

D

Would enforce.

B

That ability, with a set of roles and capabilities that have a delegation for right well.

B

Yeah.

A

They're entirely in foster and of it because you can, you could delete a tag and recreate it with a different value in most models. I believe and obviously you know, there's still the attacker scenario: the attacker coming in and modifying the registry to change the tag.

F

There's.

B

A couple I mean hacking. A registry is certainly a problem and there's some pieces. That's that I really like, but like part of the immutable tag, is view lock attack. It can't be deleted anyway, either. So there's a couple of things around that that there's some pieces in place that can at least address that problem and then I think it's made. It was just referring to like if you, if somehow it was deleted and replaced, then the idea is that the replacement wasn't signed.

B

So this is where the threat model stuff comes in of like well. Where is the attack vectors because there's certainly lots of them along the way that we want to try to figure? How do you protect against and.

C

There are ways you can cryptographically do this so, for example, with an append-only lock, you can do this. The thing is: we need to figure out what the problem is, such as this locking tags like, if that's a requirement that we need to build into our design. I, just I knew you were saying something.

D

Yeah I was actually saying that the way you would do this in tough is you wouldn't end up trusting the repository or registry in order to do this action because you would upload the sign metadata in you would effectively not update that tag anymore, not have the user. That's that is the one that's responsible that has the key. Have them. You know, go and be this walking and so like using it in this way.

D

Just just for this one like specific problem, it helps to remove the fact that you're you're, relying on the registry for enforcement of this property in other scenarios. So even if an attacker breaks into a registry, at least for any client that has some prior metadata, which you know doesn't have to be a pure update case, but can being your trust on first use means that you have at some point pre-loaded, and then you know when you do your local deployment you're, including some of that metadata, as we discuss as you would like.

D

Preload registry keys and location and stuff, then that um that cryptographically signed information effectively you're now not ending up trusting the registry to enforce that that property, which is is from a security standpoint better because no longer is it just some access control thing, but it actually, you know, has someone would have to steal the key from the owner and then make changes that way.

B

So one of the things- and this is part of what I'm hoping this sketch will come out and you know in trying to write up some the end end scenarios to flush through this is is that new ephemeral, client and one of the things that I'm hearing is you know. Obviously, we trusting just one entity is bad, whether it be the registry or a single user, with a key and so forth and key in this case. Let's talk about the nuclear submarine thing right.

A

This is always us.

B

To a minimum of two that have to agree so if they, if we can't trust the client, because the clot that we can't trust, think they're trying could have got hacked as well. But the fact is, the client is a new client being doled out for use and there's nothing there yet specific to that environment. That I need to be able get that information and I'm and I apologize for posting. This, just like a half an hour before the meeting, I didn't get a chance to read the replies, but what I liked about that?

B

What you're trying to do there is the original design from what I was reading. Is that a client has some piece of information and I have to correlate the the registry, in this case the repository and my client to see if they got out of sync and something got hacked if I, don't? How do you have any information on the client then and I can't solely trust? The registry, then, is there some other entity that would also have to get hacked as well, and what would that look like? What is that other entity.

D

So as I understand it from what we were talking about before when we were talking about deployment scenarios, you're using stock receipts or something else like this to load in information about like go to this registry and use these keys and so on, and so, if you're loading in that initial metadata in and that metadata includes just like you know, an initial copy of like the top metadata, which isn't much larger than just the list of keys. Depending on what you know how you set things up.

D

But if you set them up in the way I think we described, then that actually is the place. That provides you that extra assurance and.

B

Then.

D

Wind it winner from.

B

There's a question because, like the like, the weather I've been hearing, you say is the tough metadata is in the repository the registry we repository within a registry. So if I have.

D

A client and I have to initialize it. Where do we get it from I'm, saying something slightly different, so as a new client forget about whether using tough or anything else, right, you're, gonna get keys and things loaded in to you via dr. secrets or some other mechanism, like that, so app secrets into your container spiffy spy or whatever, somehow you're gonna end up getting like like the like the sort of like secrets and configuration and whatever else you need. So that's great configuration information.

D

You know, which is often no a key or some URLs, with a like secure hash of the thing, you're downloading or whatever else.

B

Yeah, that's it you're. Actually saying that part, that's that's the part we don't have. Yet. If we, the client has creds of some sort that says it can pull from a registry. It has some policy that says what it can do, but where does it get that that metadata? That you're, referring to to then have the comparison? The.

D

Same way, it gets its cred in its policy because.

B

It goes in a separate entity. Sorry say again: we store it in a separate entity than the registry.

D

Yeah so you're getting your creds and your policy from an entity separate from the registry right right.

A

So.

D

Just your now, your credentials effectively just include the initial metadata, so.

B

There's.

D

A service that.

B

Keeps that second store in sync, because it's doing the timestamp metadata and periodically pushing it to this other entity that both would have to be hacked.

F

Configuration system and long-lived perfectly well be year old. If this recent, if recuperation a circular enforcement, requires them to be regularly updated at so any mechanism. I'm not saying it's nimble, it's not impossible, but it's definitely new. It's not terribly derived from just obtaining the person. Well,.

C

I think you just need the route metadata file, which is typically long-lived anyway, like it's supposed to expire in a year. So now your that should be all you need, then.

F

I lose the freshness basically because I start with a blind state. It's not one of them, not having the freshness and enforcement in there. It's just that. The ephemeral.

C

Well, the freshness.

F

Caring.

C

Greenville is given sorry.

C

The the freshness guarantees is given by downloading the time stamps nap shot, which can also be bootstrapped. I mean it can be a year old, which is not going to give you the strongest fresh guarantees, but certainly better than having nothing.

B

So I think that the root of what we're talking with a tale about what data and how long and so forth, is there's this other process. That is, has a different way of getting different, a path of getting information from the registry to get some snapshot. Some metadata around a particular each repo and it's stored in a secondary entity, so that a femoral client that comes in that wants to initialize there's a set of information. It has to get.

B

Obviously, if it's getting keys, there's a certain amount of trust that allows you to get the key so doesn't get the wrong keys or the wrong configuration. It says, instead of go to my trusted registry, go to bad trusted registry and download this code that will send out all credit card information, there's a certain set of boundaries that are put in place, and it's not that any one entity is trusted in more than the others is there's this correlation of.

B

In order for somebody to hack the system, they literally have to get into multiple, highly secured entities.

B

So as long as there's a process by which that takes this metadata out of the registry puts it in some other location and that process has to be almost a third trusted trust boundary. Then, as a client I come in, hey I woke up from the world. Why is everybody wearing masks? Okay, let me just get to work right.

B

It says, okay, let me get some key information from here and that's secure and based on that I go to over here and then, as part of the thing booting up, it does a check and says: ok that information I have from there matches that now I can proceed.

B

Is that kind of fit into what we're talking about, because that to me would solve some of the concerns where I've been worried about the complexity and where does it add value in this scenario? Not Paul? Obviously,.

C

Yeah, you would get that I mean so so, if you have a version of root metadata from year ago- and let's say you've made to two recent key rotations since then, this this rotation will be handled automatically for you now. One thing that will happen is that for as long as you don't update the secondary store with the latest route, your new clients will end up pulling like the latest route over and over and over again and it'll be inefficient.

C

But all you have to do is update the secondary store, and this should be a rare error situation and.

B

You can do it once a year. You can do it once a month once a week once a day. The frequency by that which you do, that is a balance of performance and security. If I understand and right right.

C

Exactly the only thing you will be pulling new clients will be pulling over and over again is basically the timestamp in a snapshot metadata. This will change a lot, but only on every pool. You're not gonna, use circle. You're, not gonna, pull all the changes in between right.

B

Because the way I think about structuring this is like a deployment. If it's a unique tag- and we have this way to lock tags, so they can never be updated, then the deployments don't need to do this kind of deeper checking. There's something there that I don't know exactly the details. Are we have to figure that out, but certainly in the build environment where it's not critically timed compared to a production deployment? It's it it'll.

B

It is a dangerous time because you have new code being pulled in and so forth that it can do these deeper checks and says: hey I am in a build environment. Do you support base image, update tags like the version of the things it's updated for security fixes it could break because the security fix breaks, functionality, compatibility so there's always extra work going on then anyway, and then we can do this tag. Update scenario where we're trying to make sure other rich metadata is done that what I? What feels good about that is I'm?

B

Doing the more complex thing at the more scary thing, when it's not a critically timed and the more critical deployment thing where I'm trying to literally start a function in less than a second and I, want to be able to get some content to be able to do that. I can still get the right level of security because I never support an updated.

B

So it seems like a balance between the two and maybe it's making sure that that's in the series, I think I have builds and the scenarios in the sketch.

C

Yeah the way, the way the design option 2 is structured right is exactly to address your concern, which is that performance is key here, you're doing one security, but you don't want to block on it. So it's deliberately designed to get you started as quickly as possible and if you want to do deeper checks, you can.

B

Spy others.

B

Just in chronic sorry, I'm.

G

Gonna say kind of agree with revisiting the scenario stuck because I think that we've come across several scenarios like this, where the because the end-to-end workflows aren't well documented whenever we're debating these scenarios, whenever we end up looking at some implementation- and it's been difficult, I think to kind of understand like what we're working towards and what problems things just solving I agree with that. I.

G

Don't think this is necessarily moving the goalposts as as much as it is realizing that we've never really had the scenarios will define so I think it actually makes sense to kind of go through and add more meat to that duck. It's something I've brought up with Omar as well on our site. On the ALW side, he plans on participating, more and I think that will at least help us understand what tough is addressing some of these problems and what the gaps are, that we need to close.

B

We had.

A

With the latest.

B

Prs on this, then, we can maybe continue to work on it here we go I'll paste this in the slack slacker team, whatever.

B

Essentially, doesn't give you the chat window when you're doing this? Okay. So definitely, let's take a look at this, make sure that we're not missing scenarios or weathers clarity. We wanted to follow up. That's the pr2, the scenarios that are in there now I.

B

Remember we wanted to separate the threat modeling from the.

B

You know kind of scenario ones, so we we saw a good start with that. The threat model ones.

B

So Justin in Cormac and Derek what I'm sure you've had this conversation around the the tag blocking stuff? If we, you know what, if we had something like that, would that help with some of this like in a spec like it, was part of a standard thing of OCI, maybe socio, be to whatever I.

A

Don't know I think that there are definitely I mean I, think there are some people who definitely want to work like that. There are other people who don't and so I, don't think it's a solution. That's gonna work for everyone, I, don't think we can impose lock tags because I think there are people who are I. You know people who are using latest and will continue to use latest and is difficult to change their behavior. So I think we can.

A

We can't make that the only behavior we I don't know if we could I mean if we could make better security guarantees. If you only use tags in an immutable way, then we might persuade more people to use immutable tags. If that were the case, if it was, if that helped us and it'd make the design better, I think I think that might be okay, and so you might get you might get better guarantee. Well, it depends on exactly what they guarantee. What that really meant, but I could say a situation.

B

Where.

A

We could we could discuss that kind of trade-off, so.

B

Initially, you went the other way. I was thinking when you started saying people following a certain pattern. Is there's people locking to digest because those are immutable, but not very friendly from length and readability, there's a locked tag which we don't really support and then there's the latest tag. I always err quote because latest should anyway a stable tag, but it's what we could do based on what we just you know said prior to this, with what trick Trish Schenk was saying with design option two I think is.

B

You could still get security on latest because we're going to need that on build. It's that it's a more heavyweight performance performance, implication thing. So, as we all see here with people learning containers, they will learn one way and it'll work and for performance reasons they want to do in a slightly different way. It's just it's becomes a tweak. So in this case it's not that it's an insecure way. It would still be secure because we did it for builds. It would just be less performant and yeah.

A

That's that that's definitely a sort of try and we could definitely that's not try to offset acceptable. Yeah.

B

Okay, I.

H

Mean for me, I, don't think there'd be much changes the spec to support something like tag walkie and I mean we could define an air case or maybe a condition where, when you upload, you can set a flag that says like mark. This is locked, but the registry may or may not ignore that, and you know in that case, for me, what I'd like to see happen more is moving tags and digests as not one or the other, but kind of two dimensions so like, for example, on container D.

H

We have tagged at digests to represent, like you could pull an image and you pull latest and then you pull latest again that same image is, is locked there as latest at what the previous hash was.

H

We keep track of the the timestamps associated with that, so I think one of the things we're missing, not just the locking but the actual like tag history and making sure that, especially for like provenance reasons inside of notary that we have, we know when everything was signed, because we know that just because a tag got updated doesn't mean that nothing is relying on. The previous tagged version for deployment is.

B

That how you do the performance performance hop, so you can see if I have the latest version by checking. If the digest matches the tag.

H

We do that yeah I mean there's like a kind of like an e-tag check. Just to see like whether or not this is the same. I mean that's not specific what we do in container D, because we we pointed at the specific, manifest the check, but that's how we that's, how we actually keep track of everything, because in container D the image name is actually the top-level reference.

H

So we actually create two tags will create one, that's like it at like a digest and one without it, so that you can keep the other one around after you pull a different version and.

B

The tag history has always been a challenges. I, don't know if I've seen me that does it really well, we certainly something we wanted to do is like if I do have an update and it's broken. How do I get to the previous one like there's, no good historical index thing so it'd be nice to have that formalized as well. That's a that's! A good fallback and usability I. Think the the locking that feels like a good trade-off. I guess is what I'm kind of getting at us. You can go all the way to digest.

B

You can go to tags with a lock and have some confidence of performance, and then you can, for what we would say is the best practice for deploy anyway and then for build scenarios. What we do want to support the updating of a tag we can do the deeper checks and we do it in a way that the client isn't assumed to be in a previously known state. We have to do this separate entity, verification process.

H

Yeah one thing to keep in mind is some implementations of the registry. The actual storage are fairly eventually consistent, so, like you could you could push up the same tag to two different? It's kind of the latest wins which isn't great, and that's really why you need something like notary or something if you really want to enforce for said, behavior I.

C

Should note that having something like the snapshot metadata actually gives you audit ability for free in this sense, if you keep adding every use natural metadata to something like a transparent log right, which is an append-only log, you, you could actually audit whether or not people have mutated tax. So that's that's an interesting property to have.

B

Yeah being able to there's no standard for a tag, update scenario for good or bad reasons, it's something we you can put in your diagnostics and logs. You know history, but there's no standard API that anybody could run for some security scanners. Hey here's the way here, BLS Stacey are a sure and Google. Do it in docker, hub and blah blah blah cool all.

A

Right thought: I wanted to talk about upon the agenda that I want to talk about that ephemeral grants thing say: yeah in particular, I'm gonna think there were two things about option: one and the signature design doc that I think a problematic one of which was the discussion we were having about actually the feasibility of constructing independent sets of images, which is pretty unclear that I can work at all. But the second thing.

B

Will ever be done it? It's not.

A

There's a side conversation that Samuel started.

A

It's not it's not clear how you could actually even partition their registries and assess sets of images with different permissions in any useful way, because you don't know what that you don't really know what a client's permissions are until you actually try and do an authorization check on it. So you don't you if you have something that can just just tells you. If something has access to something you don't you can actually create, sets from it I'm a little read the console. That's actually not the bit.

A

I want to talk about okay, but the other bit I was about was the fact that I think we need to actually have a position on ephemeral grants, because the other problem with this is that clients have different security guarantees, depending on which images they've downloaded metadata. For so effectively, we got very path-dependent security and I think we need to make. We need to have a position that ephemeral, clans are an extremely important case and therefore that's the secures. That's the security given that in the in this option one this is that's the work.

A

It's always the worst case for rollback protection. We should basically say that this is it's a Rick. This is, and it's also in the end, the other talks from last week, because I was known.

A

Last week's call, but like no role you guys to get much worse role buy protection if you haven't pulled things before you ephemeral, and we should treat this as being the normal case and optimize for that case rather than assume, rather than in that, rather than assume their clients, I've actually pulled metadata before so I think both those things effectively a ruling against option, one as being feasible, so they're, both kinda, both of those kind of mitigate towards up something more like option. Two.

A

But I was thinking as I read that the the Merkel tree design is looking.

A

Looking a bit more like a transparency log than.

A

And and like maybe, a transparency log is what we raise more, what we want in order to provide those kinds of guarantees, because it doesn't, rather than assuming, that clients constantly pulling pulling metadata from registry, whereas in fact we know that a lot of transfer, ephemeral and that's kind of that's more like what option two is starting to look like to me as it comes together. Yeah.

D

I think what you're saying makes a lot of sense, I mean I. Think we had a little bit of hesitation because we felt like a transparency. Log was adding a lot more complexity, but I think the the what I understood a little more is the difficulty of getting people to provide a more current piece of metadata themselves is in many ways higher than an entity of running something like a trans certificate, transparency log to store the like.

D

What would really be the snap shot or the hash of the snapshot so really the timestamp metadata would be, and then once you have that, then it's easy to go and re reconstruct what you need using like the effectively the Merkel tree signatures stored inside of a transparency, log yeah.

A

I kind of thinking of it essentially as a service to retrieve the information that you don't have.

A

Yes,.

D

Yeah.

A

And so, if, if we want to design something that we don't have it and having a service that gives you the information you need does start to make sense.

D

Yeah I completely agree with um I think this would be a good, a good way to do it now. Of course you want the service he trusted and da-da-da-da-da yeah yeah, but but I think I think this would be a very natural way to number the things together.

D

Okay, we can do an analysis of this and we can rewrite document to include that. We may just remove design option one altogether and try to make it coherent. It seems like that might be easier.

D

Does anyone else like I, guess, I guess? One of my questions about this is then mean that every registry everywhere uses the same thing to store its snapshot. Hashes like its timestamp metadata.

D

Do we run this as like a public service that anybody uses or what do we? How do we do this? I? Don't.

A

Know actually I mean I think that I mean I have a kind of other question about what the I mean. I think that you've been working under the assumption that the registry is the right organizational unit, size I'm, not sure that I'm convinced that that is the right size and there I guess there are so. There are two options: there's bigger than that: ie its global or there's smaller than that ie.

A

There are more roots than registries and and people there's a number of people. That's independent from the registries who are maintaining reads and I'm I think that those are still or potentially design options for the whole thing.

A

You can't come.

D

The place where we kind of landed on that is that instead, so in tough, currently the the targets, the root of your targets, metadata is comes from the root file, so the targets metadata that you care about comes from there, but well that we've sort of proposed in this is that the targets file like root is effectively your credentials that you put in like it comes in your system ahead of time. So you control that directly.

D

So the root file can be uniform and can be uniform across the entire registry, because all it controls is snapshot in time stamp. So it's no longer actually a very security, sensitive role in the system. It's gone from being super important because it controlled targets. To being you know the thing that lets you deal with compromised of snapshot or timestamp I.

D

Don't know if that made any sense or if I just said something more confusing than I meant to you, but but in that regard, then the idea would be that for all of let's say like a large registry, you would, you could happily use the same route file, because only it's only snapshot and whatever else and everybody has their own individual top level targets file.

D

This is tap thirteen by the way, if, if you're, looking to figure out where to go for this.

A

Okay, it would be helpful to kind of call that out and the doc, maybe cuz.

D

Okay, we'll make this all more clear, yeah we it's enough of. It is out of date that we probably need to, like almost start fresh, not quite start fresh, but at least look at everything and strongly revise it. All.

C

Yeah I agree especially trying out design option one which at this point, is more confusing than illuminating. Well,.

A

We think we've thrown out two options now so, which is I, think good progress, so so actually, like I, think it's yeah. It's definitely Clara. If there's is, if there's one option that we're kind of its racing all the time and then finally, rather than because it's actually, if it's, then you can just explain that one option rather than having to say there's two alternatives.

A

So.

D

Yeah a little more about what to do in the private repo case with if our option we're really moving to this, only certificate, transparency, long style thing whether they have to set up a private instance just to do that which doesn't make sense, I mean I'm, not saying it doesn't make sense they. That would be a very logical thing for them to do in that case, but we would just have to mention that, as this is the way to do it.

B

We should really be careful about. Some of these I mean we're seeing more and more and more these air-gapped environments becoming the norm and for anybody that's been following the MCR thread: we've had a changed data. Endpoints like there is customers do not like their clients having access to things that they don't own.

B

So we need to not make it only for the big companies to implement, because it's really tough difficult. You know it needs to be something. The average company can do very easily to be able to have their environment, be completely trusted and isolated, because it's not I wrote it in one of these things. This is not just you know, submarines and these large esoteric scenarios.

B

These are the average company, wants everything locked down from anything public as a standard security measure, and they only move content into that environment in a trusted way and then the way they move content into it. That's the part that gets more secure, but it's the fact that they have a an isolated environment is the standard.

D

Yeah I think having them set up container of whatever that runs through their repository or their registry having them set up under moments like the certificate transparency, log sort of thing feels like it, it might be, the right might be usable enough. I, don't know if what others think about that, but.

B

We're almost at time for a thinking time, I.

A

Mean I think we would yeah yeah we'd have to think about.

A

That but I mean that's yeah I mean. If that's, if that's what you need to run for it to be secure, then.

A

Obviously, with all of you I'm curious about whether we I mean how much we could I guess, the question is: what secure what properties are different from the regiment, whether we could bundle it into the registry, whether we could include the transparency log as part of the registry, whether or whether it oh, how that's gonna work. Oh super have to think of.

D

People in there, if you stick it in there, it's basically just the snapshot in time stamp with with keeping history. It's basically what tough does yeah but separating it out gives you this like. If somebody breaks into it, then maybe they don't have access to to both kind of things. So yeah.

A

I mean that the log model was yeah, I mean the the yes and you need other people potentially to replicate it. For you, I mean the public transparency. Log model has actually been working fairly reasonably well, and this in the sense that, like people, have lost their keys and things and it's, but not, everyone has simultaneously.

A

Yeah.

D

Okay well well, thanks, then we'll mention our thoughts in the notary, B to slack Channel, we'll try to revise I'll, try to go through with marina and anybody else, who's interested and go through and try to revise. This are things so that they make design option to be the design option and we'll talk about using this sort of transparency.

D

Log way of this to get this metadata, as as, though it is the the one true way, because I totally agree like with something Justin permex said, which is that you know looking at one option and walking down that path is easier. Is the right way to go rather than trying to pull in different directions and talk about all that, so we'll fix our mistakes in that area. Yeah.

B

And keeping track of why we switch the other one. So we don't loop back around and repeat it so having one is good, but maybe capturing why we decided to go that one versus the other to help us stay on that rail until we found the next issue.

B

Cool all right we're at time, so it looks like we've got signee next week and I know. Neos has been trying to get some key management stuff going on so encouraged to help him get quorum on a timeslot thanks. Folks, thanks.

E

Thanks goodbye.

E

You.

E

You.
youtube image
From YouTube: CNCF Notary Project Meeting 2020-06-29

Description

CNCF Notary Project Meeting 2020-06-29