Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
and/or commands used to sign things?
Do you sign and submit on separate setups? If yes, fun to see that someone uses that feature! If no, you could sign and submit in a single step by passing both -k and -p when running sigsum-submit.
Right, I noticed this but I prefer to keep privileges of commands that need private keys as minimal as possible, for easier auditing. If both -k and -p is given, the tool goes from a offline tool to an online tool that talks to remote servers. I was happy to see that you made an effort to separate these two steps, so I can tighten down permissions when running the private key operation.
It uses a 8/15 GoogleTrustFabric witness quorum in the trust policy file, not mentioned in the release notes since this information doesn't seem widely published yet.
For more diversity you could consider adding Glasklar's witness:
https://git.glasklar.is/glasklar/services/witnessing/-/blob/main/witness.gla...
Mullvad also started running a stable witness (not documented similar to Google's witness, only mentioned on Matrix a couple weeks back):
witness witness.mullvad.net 15d6d0141543247b74bab3c1076372d9c894f619c376d64b29aa312cc00f61ad
I'd probably set the threshold to 2/3 for google,glasklar,mullvad; and keep the google threshold at 8/15.
Thanks -- I'll try to do this next time.
(Note that you probably want to create a new policy file rather than updating the existing one, and then link the new file in newer announcements. Since otherwise the old instructions will break.)
I was thinking I could make changes to the trust policy file if it were a strict superset of the earlier information. What is important is that both new and old commands still work, not that the trust policy is necessarily identical, or am I missing something?
I don't like storing the rate-limiting domain token private key on disk. I noticed it is recommended to use a separate key for this, but what are the risks if people would start to use their software signing key instead? Aren't the signatures domain separated? Key management is a hassle, so reducing the number of private keys people have to manage the lifecycle for leads to a overall security improvement. I would also prefer to use my hardware-bound OpenPGP signing subkey (instead of my hardware-bound OpenPGP authentication subkey), but I haven't been able to figure out the SSH agent tooling for this.
You're right that submit and rate-limit signatures are domain separated with a namespace. So, there's no security risk for your signed checksums if you re-use the same key for submission and rate limiting.
The only caveat is that the rate-limit key is essentially used to compute token=Sign(key, <log pubkey>). Then "$domain, $token" is passed as an HTTP header to the log server when doing a submission.
The risk: if $token is somehow revealed to an unauthorized party, then that party can start spending your rate-limit. Recovery requires rotating the rate-limit key and updating your DNS TXT record. In which case you're back to having separate keys.
Further reading:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md#4--r...
Does this context help wrt. if it is safe to reuse the same key? (If it helps I would also start by using the same submit and rate limit key.)
Thanks for the link! I find this design surprising: if I understand you correctly, it means the private key is only needed once to generate the token, not on every sigsum-submit usage. So effectively the token is a long-lived key-equivalent?! I was expecting some kind of challenge-response or at least monotonically increasing signed counter, to avoid replay attacks of earlier submission tokens.
Could also be a single command:
Thanks!
sigsum-verify -k jas.pub -p sigsum-policy.txt inetutils-2.6.tar.gz.proof < inetutils-2.6.tar.gz sigsum-verify -k jas.pub -p sigsum-policy.txt inetutils-2.6.tar.xz.proof < inetutils-2.6.tar.xz sigsum-verify -k jas.pub -p sigsum-policy.txt inetutils-v2.6-src.tar.gz.proof < inetutils-v2.6-src.tar.gz
Running sigsum-verify is redundant, i.e., sigsum-submit does not give you a .proof file unless it verifies for the input and provided policy.
Okay. I find it good to actually test what end-users will run to make sure I get it correct.
sha256sum inetutils-2.6.tar.gz | cut -d' ' -f1 | base16 -d | sha256sum sha256sum inetutils-2.6.tar.xz | cut -d' ' -f1 | base16 -d | sha256sum sha256sum inetutils-v2.6-src.tar.gz | cut -d' ' -f1 | base16 -d | sha256sum
sigsum-monitor --interval 5s -p sigsum-policy.txt jas.pub
Given the tools we have right now it doesn't get better than this. I'll comment more below on the topic of writing a monitor for your use-case.
Fwiw, a sigsum-keygen sub-command to compute the SHA256(SHA256(file)) value would be useful. Initially I didn't have the 'base16' tool and it isn't that common.
Ideas for improvements?
Specify somewhere what you're claim is. To me it looks like the claim is: you will only sign checksums that can be reproduced from source at $LOCATION, see $R-GUIX-JOB. This is what I'm sketching a monitor on.
The claim could also include where you publish release announcements, in which case the monitor could try to falsify something like: "official releases are announced at $MAILING-LIST". So if you ever make a release without announcing it there, then the monitor could flag it as well.
(Claims are helpful so monitors know what to falsify / verify.)
Thanks! The concept of "claims" really helps to make the concepts understandable to my mind.
Unfortunately it is not clear to me what I think is useful to actually claim here. The R-GUIX-JOB is complex and tied to the GitLab pipeline infrastructure. I don't think it is a very good claim going forward. You may find the B-Guix job simpler - effectively ./bootstrap + ./configure + make dist after adjusting for build dependencies.
I think a better claim would be something like: I claim to sign only source tarballs that were prepared reproducibly via 'make dist' by me by using 'guix time-machine ...' in a git checkout of the tagged commit. The 'guix time-machine' command should be a complete command that people can run to reproduce the tarball.
We don't know if the 'guix time-machine' will actually work in 10 years, but I don't know of any other approach available that offers any similar promise. Specifying a particular Debian snapshot timestamp and related commands get complex quickly. I think most normal GNU/Linux operating system doesn't give me the kind of behavior that is needed here.
Are you able to build a "libtasn1 release monitor" out of this information?
From a quick glance it seems possible, yes.
Sketch:
Monitor tails release tags from the git repository. For each release tag, run the rebuild recipe and arrive at the expected checksums. Now we basically have a list of (release tag, checksums) pairs. In your case it looks like there are three checksums per release tag.
Monitor tails sigsum logs in the trust policy, filtering entries on your submit key. And ensure it sees enough cosignatures for your trust policy. Now we basically have a list of signed checksums that users would have accepted as valid.
Compute the diff between checksums in the log and checksums that were reproduced. If there's ever a checksum in the log that haven't been reproduced from source, flag it and escalate to the monitor's operator.
This might happen if:
- There is a reproducibility issue
- Submit key signed something that's out of tree (hidden release)
If there is a claim about where official release announcements are, the monitor could also verify that all releases have been published there.
Great! The main thing to improve here, I think, would be to establish some commonality for the "run the rebuild recipe" step. How about mandating that a script ".sigsum/reproduce-release-artifacts" should be present to support Sigsum artifact reproduction? Maybe that is useful beyond Sigsum even.
/Simon