|
I didn't do a deep dive, but it looks like the "simple signing" design from Fedora would enable an attacker that has compromised the signing server to compromise user devices (even with HSMs, etc.). I also wasn't sure if there was a secure way to do key revocation in the case where an incident did occur. These sorts of issues happen a lot more than one would expect [1-5] plus see [6] for dozens of other incidents.
TUF is designed to handle exactly these kinds of incidents while still retaining a high degree of security. Actually, many ideas in TUF came out of security issues we found in YUM, APT, and other package managers [7,8]. We integrated ideas from an earlier system of ours into YUM, APT, YaST, Pacman, etc. back around 2009.
I'd be happy to talk more if there are any questions or thoughts, but want to keep this being too long or from rambling too far off-topic...
Thanks,
|
|
|
Thanks Justin, that is very helpful & certainly length-appropriate.
On Thu, Jun 22, 2017 at 3:50 AM, Justin Cappos via cncf-toc <cncf-toc@...> wrote: I didn't do a deep dive, but it looks like the "simple signing" design from Fedora would enable an attacker that has compromised the signing server to compromise user devices (even with HSMs, etc.). I also wasn't sure if there was a secure way to do key revocation in the case where an incident did occur. These sorts of issues happen a lot more than one would expect [1-5] plus see [6] for dozens of other incidents.
TUF is designed to handle exactly these kinds of incidents while still retaining a high degree of security. Actually, many ideas in TUF came out of security issues we found in YUM, APT, and other package managers [7,8]. We integrated ideas from an earlier system of ours into YUM, APT, YaST, Pacman, etc. back around 2009.
I'd be happy to talk more if there are any questions or thoughts, but want to keep this being too long or from rambling too far off-topic...
Thanks,
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
Just wanted to weigh in from CoreOS. We are using Notary for signing packages as well for the Quay container registry running at Quay.io.
Signing packages is tricky and TUF seems to get things right. I would also add that there's nothing preventing GPG integration in the future if that's desirable (for key management and signing operations, not instead of TUF metadata). I believe rust-tuf has that as a goal.
|
|
|
Follow-up questions on Notary: - What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository?
- Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
- The main benefit compared to just signing an image digest is revocation?
- Who owns https://github.com/theupdateframework/tuf ? It's not clear from the readme or authors files.
- Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
Thanks.
|
|
|
David Lawrence <david.lawrence@...>
Hi Brian,
Justin Cappos CC'd will have to answer on the precise ownership of the tuf repo. Answers to the other questions follow:
- What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository?
- Content (images) is considered to have a canonical name independent of where it is stored. Notary servers will happily service any names for which they are configured (generally this means they will service any name the requesting user can get a JWT for from the appropriate authorizing server for which notary holds a public cert). Containerd has been working recently to support this same model. A given notary server will serve consistent data for a given name, and one notary server can be used to service many image repositories. A key thing to note is that the name of the content must be consistent, this is because that name is included in the notary repository. This reduces the chance that notary data can be misused in the case that a key is reused across multiple repos. I'm happy to go in to more depth if that's interesting, it's just a long, complex explanation, and this is already a relatively verbose answer.
- Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
- Absolutely, this is one of the things the docker security team has been pushing in our secure software supply chain talks over the last year+
- The main benefit compared to just signing an image digest is revocation?
- Other significant benefits I would count as equal to revocation: freshness, delegation to alternate signers, painless key compromise recovery in many situations (this one I would put higher than revocation as a benefit).
- Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
- Not explicitly, it would be very short. TUF is a description of a minimal data structure and update process, Notary is a Golang implementation of that, and DCT is an integration of Notary in to docker (with some opinions on delegation priority and which keys are online vs offline)
If more explanation is needed I'm happy to provide it, or if I missed the mark on any of the answers, let me know.
Thanks,
David
On Mon, Jul 10, 2017 at 6:54 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: Follow-up questions on Notary: - What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository?
- Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
- The main benefit compared to just signing an image digest is revocation?
- Who owns https://github.com/theupdateframework/tuf ? It's not clear from the readme or authors files.
- Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
Thanks.
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
I own the repo (and just made that clearer in the authors / readme). Thanks for pointing that out!
Justin
On Mon, Jul 10, 2017 at 10:20 PM, David Lawrence <david.lawrence@...> wrote: Hi Brian,
Justin Cappos CC'd will have to answer on the precise ownership of the tuf repo. Answers to the other questions follow:
- What is the degree to which trust is tied to the distribution mechanism? Can image identity be asserted independent of the distribution mechanism and, if so, how is that identity expressed? As a concrete example, if an image were pushed to multiple image repositories, would it need to be signed multiple times, one for each repository?
- Content (images) is considered to have a canonical name independent of where it is stored. Notary servers will happily service any names for which they are configured (generally this means they will service any name the requesting user can get a JWT for from the appropriate authorizing server for which notary holds a public cert). Containerd has been working recently to support this same model. A given notary server will serve consistent data for a given name, and one notary server can be used to service many image repositories. A key thing to note is that the name of the content must be consistent, this is because that name is included in the notary repository. This reduces the chance that notary data can be misused in the case that a key is reused across multiple repos. I'm happy to go in to more depth if that's interesting, it's just a long, complex explanation, and this is already a relatively verbose answer.
- Could attributes other than identity (e.g., passage of certain types of validation/qualification tests) be attested by this mechanism? If so, could they be created by someone other than the image repository owner?
- Absolutely, this is one of the things the docker security team has been pushing in our secure software supply chain talks over the last year+
- The main benefit compared to just signing an image digest is revocation?
- Other significant benefits I would count as equal to revocation: freshness, delegation to alternate signers, painless key compromise recovery in many situations (this one I would put higher than revocation as a benefit).
- Is there any doc that describes the important distinctions between the capabilities of TUF, Notary, and DCT?
- Not explicitly, it would be very short. TUF is a description of a minimal data structure and update process, Notary is a Golang implementation of that, and DCT is an integration of Notary in to docker (with some opinions on delegation priority and which keys are online vs offline)
If more explanation is needed I'm happy to provide it, or if I missed the mark on any of the answers, let me know.
Thanks,
David
|
|
|
