Re: Notary/TUF: marshalled and ready to activate


Chris Aniszczyk
 

Thanks Quinton for the detailed followup.

I plan on calling a vote by Monday at the latest.

On Mon, Sep 25, 2017 at 5:52 PM, Quinton Hoole via cncf-toc <cncf-toc@...> wrote:
I think we’re good to go, with the caveat that the comparison matrices covering other update frameworks are still somewhat misleading and/or inaccurate (depending on your perspective), and should IMO be disregarded, and ultimately updated or deleted.

Most widely used trusted software update mechanisms can, in practice, check most of the boxes in the matrices, but TUF/Notary consolidates the required functionality into a single, well-defined, reviewed framework.

As long as we’re clear on that, I think that we have all of the info necessary to vote.  Thanks to the Notary folks (and @endophage in particular) for your diligence and patience attempting to address all of the questions and concerns expressed.

FYI to the voting TOC members as context, below are a few illustrative comments that have been made by the community regarding the comparison matrices:


FWIW, the YUM part above is not correct as such.

At SUSE we use GPG detach signed YUM repositories and it gives most if not all security features needed.

YUM has a root repomd.xml with sha256 hashes of dependend files all the way down. SUSE and likely others sign to repomd.xml with a trusted GPG key with detached signature.

  • freshness: at SUSE we have added an expiry tag to guarantee this
  • mix and match: is caught implicitly (the whole YUM repo is signed as a single blob)
  • endless data attack: needs to be caught by YUM processing stack, YUM format includes sizes everywhere
  • extraneous dependencies: implictly caught (whole YUM state is signed as a single blob)
  • fast forward: implicitly caught (whole YUM state is signed as a single blob)
  • indefinite freeze: caught by freshness attribute
  • malicious mirrors ... well, notary has the same trouble. the freshness will show this to the user.
  • rollback attacks: depends on how YUM is used, but RPM based installations usually only have increasing versions only.
  • slow retrieval: depends on YUM downloader, but with the sizes known ahead in YUM its at the same level as in TUF

What is a problem is that YUM is a bit RPM centric and does not support plain files, so a new XML part that handles generic files would need to be added.

I also admit that key handling is limited to a single GPG key signing the whole YUM repository instead of multiple roles/keys like in Notary, so some of the key attacks are present in YUM+GPG.

But its not as bad as your graphics makes it to be.


————————


https://github.com/cncf/toc/pull/38#issuecomment-329091834


I just spoke to one of the APT developers while at OSS and it appears that Debian/Ubuntu packaging also solves most of the problems you've marked as "not handled" (similarly to what @msmeissn has been describing for zypper/yumrepo). I would be also shocked to discover that RedHat's dnf and yum do not solve these problems (to the same degree as zypper/apt/etc) as well…


———————


https://github.com/cncf/toc/pull/38#issuecomment-329758267


…I agree however, that the comparison table should be updated to match how the actual package managers in distributions behave to mitigate individual risks.


————————


It is clear that many of the Linux vendors have started to construct parts of a protocol set similar to TUF using GPG, but there does not appear to be a formal reviewed specification in the same way as TUF has defined, with detailed security review, at least as far as I can find. The discussion about which boxes in the table should be ticked, and the fact that no one can easily find definitive answers does suggest that the specification is ad hoc rather than formally specified like TUF, or the answers would be much easier to find.

Q

Quinton Hoole

Technical Vice President

America Research Center

2330 Central Expressway, Santa Clara, CA 95050

Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9

Email: quinton.hoole@...   ID#Q00403160


From: <cncf-toc-bounces@....io> on behalf of Brian Grant via cncf-toc <cncf-toc@...>
Reply-To: Brian Grant <briangrant@...>
Date: Friday, September 22, 2017 at 06:33
To: Alexis Richardson <alexis@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Notary/TUF: marshalled and ready to activate

I am ready

On Sep 22, 2017 1:16 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:
Hi all

I think we are ready to start soliciting votes for Notary.  Please shout now if you disagree, especially if you have been a TOC Contributor carrying out DD.

There were questions about TUF.

My understanding from OCI is that container signatures are expected to be attached metadata that could be associated with any popular method eg gpg, tuf.  If the OCI standardise this then they will focus on making it possible to attach signatures, rather than on picking gpg vs tuf for example.

By the same token (no pun intended) the CNCF is not, I repeat not, blessing a standard.  We should make this clear beyond the possibility of confusion.  TUF is a spec.  But we are not saying it is a standard.  See the github thread for more.

I want to thank Dan and all the DD folks for help thus far.

Are we ready to start voting?


Alexis




_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




--
Chris Aniszczyk (@cra) | +1-512-961-6719

Join cncf-toc@lists.cncf.io to automatically receive all group messages.