diff options
| -rw-r--r-- | README.md | 60 |
1 files changed, 41 insertions, 19 deletions
@@ -44,41 +44,63 @@ uptime, stability, etc. In the meantime you may get your hands dirty by running STFE locally. Rough documentation is available [here](https://github.com/system-transparency/stfe/blob/main/server/README.md). -## What should be considered? +## What was considered? +### Gossip-audit model Simply adding something into a transparency log is a great start that has merit on its own. But, to make the most of a transparency log we should keep the following factors in mind as the ecosystem bootstraps and develops: -1. Client-side tooling should ultimately fail-close if a signed checksum is not -transparency logged. This requires a reliable and available log ecosystem. -This is easier to achieve if there are multiple independent log operators. -2. Client-side tooling should verify that the signed checksums appears in a log. -This requires inclusion proof verification. STFE forces this by never issuing +1. Clients should verify that the signed checksums appear in a log. This +requires inclusion proof verification. STFE forces this by never issuing so-called _promises to log_ as in [Certificate Transparency](https://tools.ietf.org/html/rfc6962).<sup>[2](#footnote-2)</sup> -3. Client-side tooling should verify that the log is append-only. This requires -consistency proof verification. -4. Client-side tooling should convince themselves that they see the same append-only -log as everyone else. This requires a well-defined gossip-audit model. +2. Clients should verify that the log is append-only. This requires consistency +proof verification. +3. Clients should convince themselves that they see the same append-only log as +everyone else. This requires a well-defined gossip-audit model. That last point is often overlooked. While transparency logs are verifiable in theory due to inclusion and consistency proofs, _it is paramount that the different parties interacting with the log see the same entries and cryptographic proofs_. Therefore, we built a proactive gossip-audit model -directly into STFE: _witness cosigning_.<sup>[3](#footnote-3)</sup> The idea is that many independent -witnesses _cosign_ the log's STH if and only if they see a consistent -append-only log. If enough reputable parties signed-off the log's cryptographic -state, you can be pretty sure that you see the same log (and thus the same -checksums) as everyone else. +directly into STFE: _witness cosigning_.<sup>[3](#footnote-3)</sup> +The idea is that many independent witnesses _cosign_ the log's STH if and only +if they see a consistent append-only log. If enough reputable parties run +witnesses that signed-off the same STH, you can by corollary be pretty sure that +you see the same log (and thus the same checksums) as everyone else. Moreover, if you already rely on witness cosigning for security, all you need from, say, a software publisher, is an artifact, a public verification key, a -cosigned STH, and an inclusion proof up to that STH. That is excellent -because client-side verification becomes completely non-interactive! +cosigned STH, and an inclusion proof up to that STH. To clarify why that is +excellent: client-side verification becomes completely non-interactive! + +### Ecosystem robustness +Our long-term aspiration is that clients should _fail-close_ if a checksum is +not transparency logged. This requires a _robust log ecosystem_. As more +parties get involved by operating compatible logs and witnesses, the overall +reliability and availability improves for everyone. An important factor to +consider is therefore the _minimal common denominator_ to transparency log +checksums. + +STFE uses a leaf type that contains just enough information to establish a +context for clients and monitors: +1. What entity should the checksum be attributed to (follows from signature and +namespace). +2. What does the checksum refer to so that the data can be located (identifier). + +Additional metadata needs can be included in the data that the checksum covers, +and the data itself can be stored in a public unauthenticated archive. It would +be more difficult to build compatible logs if everyone wanted their own leaf +type. Similarly, log APIs and data formats should ideally suit all. We are +still thinking about that. + +### Spam mitigations +Important factors: leaf is small, leaf is signed. ## <a name="footnote-1">1</a>: -The academic literature documents this challenge quite well with regards to -Certificate Transparency. See, for example, the work of +The lack of gossip-audit models that prevent and/or detect _split-views_ is +documented quite well with regards to Certificate Transparency. See, for +example, the work of [Chuat _et al._](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7346853), [Nordberg _et al._](https://tools.ietf.org/html/draft-ietf-trans-gossip-05), and [Dahlberg et al.](https://sciendo.com/article/10.2478/popets-2021-0024). |