diff options
| -rw-r--r-- | archive/2022-02-08-timestamp-reflections.md | 60 | ||||
| -rw-r--r-- | doc/proposals/2022-02-end-user-terminology.md | 21 |
2 files changed, 81 insertions, 0 deletions
diff --git a/archive/2022-02-08-timestamp-reflections.md b/archive/2022-02-08-timestamp-reflections.md new file mode 100644 index 0000000..9cd4c46 --- /dev/null +++ b/archive/2022-02-08-timestamp-reflections.md @@ -0,0 +1,60 @@ +# Timestamp reflections +## Introduction +Sigsum logs sign tree heads that contain timestamps. Witnesses must not cosign +a tree head unless the timestamp is fresh. The original motivation to have a +timestamp was to ensure that monitors could be convinced of freshness. This +document provides some of our latest insights on the why (not) of timestamps. + +## Background +A witness must only cosign a tree head if it is fresh and append-only. The +freshness criteria is defined as "not older than five minutes". This means that +logs and witnesses are assumed to be configured with some kind of rough time. + +Simply removing the freshness check would introduce the risk of slow-down +attacks against monitors. See [past documentation][] on how that works. + +[past documentation]: https://git.sigsum.org/sigsum/tree/archive/2021-08-24-checkpoint-timestamp + +## Freshness without timestamps +Assume that a witness only cosigns a tree head if the current tree size is +larger or equal to the previous tree size. A different way to approach +freshness for monitors without appealing to reactive gossip is as follows. + + 1. Every X time units, submit an entry for logging. + 2. Check that the submitted entry gets merged in the next cosigned tree head, + and that the cosigned tree head has enough cosignatures to be trusted. + +A monitor can conclude that at the time its latest entry got merged into the +log, there cannot be any other outstanding entries unless there is a split-view. +A split-view is not possible unless the witnessing assumptions is wrong. So, +within our threat model this can prevent a slow-down attack without timestamps. + +The downside is that monitors must submit entries periodically to repeatedly +convince themselves of freshness. It does not preclude the idea, but does not +necessarily work if the same cosigned tree head format is used elsewhere. For +example, a [serverless transparency log][] might not want to allow write-access +to each and every monitor. A different approach towards freshness is needed. + +[serverless transparency log]: https://github.com/google/trillian-examples/blob/master/serverless/README.md + +## Other timestamping arguments +An interesting property from having witness-verified timestamps is that a clock +can be set roughly by doing the above submission trick once at start-up. A +system that already relies on witnesses for append-only logs can get rough time. + +An interesting side-effect of witness-verified timestamps is that the setup as a +whole results in a distributed timestamping service. It is easy to get excited +about this property. It is not a strict Sigsum criteria, however. + + 1. Get the current cosigned tree head `X`. + 2. Log an entry `E`. Leaf index will be larger or equal to `X.tree_size`. + 3. Get inclusion proof to a newer cosigned tree head `Y`. + 4. Now a third-party that be convinced that `E` was logged in the interval + `[X.timestamp, Y.timestamp]`. + +(A bit-for-bit duplicated entry should be considered log misbehavior.) + +Some policy aspects could become easier with timestamps, such as "witness W +should not be trusted for timestamps after time T". The same statement can be +stated without time though: "witness W should not be trusted after tree size N". +The difference is that a timestamp works for all logs; tree sizes are per-log. diff --git a/doc/proposals/2022-02-end-user-terminology.md b/doc/proposals/2022-02-end-user-terminology.md new file mode 100644 index 0000000..9b6df79 --- /dev/null +++ b/doc/proposals/2022-02-end-user-terminology.md @@ -0,0 +1,21 @@ +# Background +We are not entirely happy with the terminology "signer" and "verifier", see +[earlier proposal][] and [meeting minutes][]. At a first glance "author" seemed +like a good abstract description. More work was needed to replace "verifier". + +[earlier proposal]: https://git.sigsum.org/sigsum/tree/doc/proposals/2022-01-author-reader-terminology +[meeting minutes]: https://git.sigsum.org/sigsum/tree/archive/2022-01-18--meeting-minutes + +# Proposal +1. Keep the terminology "signer". +2. Replace "verifier" with "end-user" + +The motivation for keeping "signer" is that it feels natural when we have +conversations about Sigsum. The other natural term for the party which will use +the signed data in the end is "user". We often say "end-user" for emphasis. + +# Notes +Signer will continue to be overloaded. We should be upfront about this where +there is risk for confusion (logs and witnesses are also signers of tree heads). + +Not introducing abstract terminology unless it is needed is likely a win. |