Sigsum-general November 2023

sigsum-general@lists.sigsum.org

3 participants
4 discussions

Any value in storing tree head signatures locally?
by Niels Möller 21 Nov '23

21 Nov '23

Hi, I'm looking at my draft MR for persisting monitor state (https://git.glasklar.is/sigsum/core/sigsum-go/-/merge_requests/152). There's a bit of extra complexity there because the monitor stores treeheads *including* signature. Those signatures are verified when it is restarted and state is read back from disk. It's not clear to me that provides any real value, though. Do we lose anything if we verify signatures when tree heads are received from the network, and then discard the signatures and just trust local system integrity? One attack I'm thinking of: Say leaf 17 records some malicious act that the monitor would flag. If the monitor can be taken down when it has processed the log up to leaf 15, and then have it's state fast-forwarded so that when it is restarted, it thinks it already have looked at everything up to leaf 20, that's a problem. However, (i) verifying the tree head signature doesn't help; since attacker can get a properly signed later tree head by just asking the log, and (ii) if the attacker is control of the local storage, monitoring is broken anyway. Almost the same question applies to witnesses, which also needs to persist latest observed and cosigned tree head. My witness implementation stores the log's signature and its own cosignature, and verifies both when state is loaded at restart. The relevant attack here is forcing the state backwards, rather than forwards, but the signatures appear to not provide any protection against that attack either. And in either scenarios, in case the treehead is modified in any other way than to a different valid treehead in the past or in the future, that should result in a consistency error when the monitor/witness received the next treehead from the log. Am I missing something, or can we just drop local storage of tree head signatures? Regards, /Niels

2 3

On k-of-n witnessing
by Niels Möller 17 Nov '23

17 Nov '23

Not sure if this is already well known and documented somewhere, but I'd like to sort out the implication of dishonest witnesses. Say there are a total of n witnesses, m of which are honest. The other n-m are willing to participate in either denial of service (refuse to cosign anything) or split-view attacks (cosign multiple inconsistent tree heads). Assume client policy requires at least k valid cosignatures. To thwart denial of service attacks, we must have k <= m. For a split-view attack, the attacker wants two clients (with the same policy) to accept two distincts views of the log. It seems the best the attacker can do is to have each view the tree cosigned by half of the honest witnesses and all of the dishonest witnesses, so that the number of valid cosignatures on each view is n - floor(m/2), n - ceil(m/2) The attack succeeds if both are accepted, and it is thwarted if k > n - ceil(m/2) We would like to have at least one value of k that is secure, and that would have to be k = m, and then we need k > n - ceil(k/2) which should be equivalent (if I get the details of ceil and floor logic right) to k > 2n/3 and k >= 1 + floor(2*n/3) So a little table, n 1 2 3 4 5 6 7 8 9 10 min k 1 2 3 3 4 5 5 6 7 7 The important point here, is that if one uses a k-of-n policy with smaller k than in this table, say, 5-of-8 witnesses, then it is *not* sufficient with 5 honest witnesses to reject a split view, since we could have a split view with 5 and 6 cosignatures on each view. And 6 honest witnesses isn't enough either, we need at least 7, i.e., we can tolerate at most a single dishonest witness. It also seems worth noting that we need at least 4 witness before we can have any redundancy. Regards, /Niels

1 0

ANNOUNCE: Sigsum Log Server Protocol version v1.0.0
by Niels Möller 08 Nov '23

08 Nov '23

The Sigsum team is happy to make the first official release, version v1.0.0, of the Sigsum Log Server Protocol. This is the protocol used to submit new entries to a Sigsum log, and to query the log for cosigned tree heads, stored entries, and for inclusion and consistency proofs. See https://www.sigsum.org/ for more information about the Sigsum project. NEWS file entry for this release is appended below. This release of the specification can be read at https://git.glasklar.is/sigsum/project/documentation/-/blob/log.md-release-…. The specification will also be published on https://www.sigsum.org/. /The Sigsum team NEWS for log.md, version v1.0.0 This is the first official release of the Sigsum Log Server Protocol, i.e., the file log.md. This release is identified by the git tag log.md-release-v1.0.0. It is intended to be stable, and there are no planned breaking changes. See README.md for information on development and release processes for Sigsum specifications. The protocol is implemented by the log-go server v0.14.1 announced recently, see https://git.glasklar.is/sigsum/core/log-go/-/blob/v0.14.1/NEWS, and by the command line tools at https://git.glasklar.is/sigsum/core/sigsum-go, current version being v0.6.1.

2 1

ANNOUNCE: log-go v0.14.1
by Niels Möller 01 Nov '23

01 Nov '23

The Sigsum team is happy to release a new version of the log-go log server software, version tag v0.14.1, succeeding the previous release v0.9.0. The source code for the release can be checked out from the git repository as git clone -b v0.14.1 https://git.glasklar.is/sigsum/core/log-go.git or installed using go install sigsum.org/log-go/cmd/sigsum-log-primary@v0.14.1 This release updates the log to the version 1 Sigsum protocol. It also adds back support for witness cosigning, following an interim witness protocol. See NEWS file for details on changes and how to upgrade, excerpt below. If you find any bugs, please report them here on the sigsum-general mailing list or open an issue on GitLab in the log-go repository: https://git.glasklar.is/sigsum/core/log-go/ The expectations and intended use of the log server software is documented in the log-go RELEASES file. You will also find more information about the overall release process there, see https://git.glasklar.is/sigsum/core/log-go/-/blob/main/RELEASES.md. / The Sigsum team NEWS for log-go v0.14.1 This release updates the log server to implement the v1 sigsum protocols [1]. The log protocol, i.e., the protocol for querying a log and submitting new entries, is now considered stable: there are no plans for incompatible changes, and future updates will consider transitions carefully. However, the witness protocol, used by logs to interact with witnesses, is under development, and will likely be replaced in later versions. Upgrading existing log services from the previous release, v0.9.0, is automatic, see below for the implications of upgrading. However, downgrading is *NOT* tested nor supported. Downgrading would require manual replacement of the signed-tree-head file by restoring it from a backup or recreating it using sigsum-mktree. This release has been tested to work together with: * Command line tools (most importantly sigsum-submit and sigsum-verify) https://git.glasklar.is/sigsum/core/sigsum-go, tag v0.6.1. * The prototype witness, https://git.glasklar.is/sigsum/core/sigsum-py, tag v0.1.1. * The litetlog witness, https://github.com/FiloSottile/litetlog, tag v0.1.1. New features: * Implemented a new interim witness protocol [2], where a log queries witnesses for cosignatures. Witnesses to use are configured using a sigsum policy file. Further changes to the log <-> witness protocol are planned. Incompatible changes: * Tree head serialization used for signatures and cosignatures changed to use a checkpoint-compatible [3] text serialization. * Leaf signatures as well as submit token signatures changed to no longer use SSH signature format. Notes on upgrading: * Existing logs can be upgraded. When loading a log server's signed-tree-head file, the server accepts either a sigsum v0 tree head signature, as created by log-go v0.9.0, or a v1 signature, as created by the current version. * An upgraded log will publish tree heads signed according to the v1 protocol, and accept new leaves signed according to the v1 protocol. * Old leaves submitted according to the v0 protocol obviously stay in the tree, but they will appear invalid to anyone who has the submitter's public key and attempts to verify the leaf signature according to the v1 specification. * Old sigsum proofs can still be verified using old tools (since verification is purely offline, the log server is not involved at all). However, attempting to create a new proof for an old leaf will fail. Miscellaneous: * An intermediate version, tagged v0.13.0, included an explicit "v1" signature version on the cosignature lines. This protocol change was reverted for v0.14.x. Version v0.13.0 was never announced or properly released, but in case anyone is nevertheless running v0.13.0, upgrading to v0.14.1 is expected to work. The only user-visible change is the removal of cosignature version, which means that any client software and witnesses written to interop with log servers running v0.13.0 will need upgrading as well. [1] https://git.glasklar.is/sigsum/project/documentation/-/blob/main/log.md [2] https://git.glasklar.is/sigsum/project/documentation/-/blob/4ee138f1294f9c1… [3] https://github.com/transparency-dev/formats/blob/main/log/README.md#checkpo…

2 2

2024

2023

2022

2021

Sigsum-general November 2023