diff options
Diffstat (limited to 'content/post')
4 files changed, 547 insertions, 0 deletions
diff --git a/content/post/hold-on-to-your-hat-and-learn-system-transparency-in-five-minutes.md b/content/post/hold-on-to-your-hat-and-learn-system-transparency-in-five-minutes.md new file mode 100644 index 0000000..978791d --- /dev/null +++ b/content/post/hold-on-to-your-hat-and-learn-system-transparency-in-five-minutes.md @@ -0,0 +1,146 @@ +--- +title: "Hold on to your hat and learn System Transparency in five minutes!" +date: 2020-10-12 +--- +What do we really know about the systems that run our critical applications? +Not enough is probably a fair summary: much can go wrong between device reset +and execution of a user-land application. System Transparency helps you verify +that what you think is running remotely actually runs, and not, say, a modified +operating system that contains a secret backdoor. I will break it down +top-to-bottom after first motivating the rationale and objective briefly. + +## Rationale and objective +Anyone in a position of power should probably be subject to a proportional +amount of transparency. It is an important safeguard that deters malicious +activities, while at the same time making it possible to fix honest mistakes. +Such a principle can of course be applied in real life, but I mainly refer to +the different components that compose a digital system: hardware, firmware, +operating systems, applications, and so forth. Generally I would say that _power +is decreased by transparency because most abuse can be detected_. For example, +it would be proportional by Intel to open up their proprietary management engine +because it is powerful enough to + [hijack your system](https://www.wired.com/2017/05/hack-brief-intel-fixes-critical-bug-lingered-7-dang-years/). + + +The scenario to keep in mind is accordingly as follows. A remote server is +running a service somewhere that processes your data based on a policy. You +might have reason to believe that said policy is followed now, but will it be +in the future when + [intruders](https://www.eff.org/deeplinks/2020/07/after-weeks-hack-it-past-time-twitter-end-end-encrypt-direct-messages) +and + [law enforcement](https://www.eff.org/cases/apple-challenges-fbi-all-writs-act-order) +knock down the door? I, for one, would prefer if we could _verify_ that the +system in question works as intended (and not just trust that to be the case +blindly). The other benefit of such remote system verification is more subtle: +the service provider could use it to determine if intention matches deployment. +Of course there might be unknown bugs, but by making every part of the system +as transparent as possible it will be easier to find vulnerabilities and assess +trustworthiness. + +## Breaking it down, top-to-bottom +The idea is to first make transparent what is allowed running on a given system. +You can view this as the top-most layer that represents an operating system +package with installed programs, configurations, and so forth. Thereafter we +need to enforce that nothing else than the transparent operating system package +is allowed running with a bottom layer. Such enforcement is based on hardware +features that should be transparent as well. + +### Reproducible and publicly auditable operating system packages +Suppose that we have an operating system package that we would like to deploy. +As a first step we need to + [build it reproducibly](https://reproducible-builds.org/), such that anyone can inspect +the source code and determine if the resulting package lives up to the claimed +promises. A possible issue that one might find, for example, is that there is +interactive system access installed: pretty much anything could run after a +reconfiguration. Therefore, a transparent system should restrict arbitrary +access and provision updates as new operating system packages that, again, +build reproducibly. For those that are familiar with functional programming, it +is essentially an + [immutable infrastructure](https://web.archive.org/web/20200518230417/http://chadfowler.com/2013/06/23/immutable-deployments.html). +An independent benefit of such maintenance is that + [malware persistence](https://github.com/Karneades/malware-persistence#overview-of-often-and-less-often-used-persistence-mechanisms) +becomes trickier. + +A reproducible operating system package serves a limited purpose unless it is +publicly available. Therefore, we should insert it into a + [transparency log](https://transparency.dev/). +This means that anyone can verify whether a package builds reproducibly, and if +it contains, say, a secret backdoor that would be detected by source inspection. + +### Measured and remotely attested boot +Now we need to enforce that the publicly disclosed operating system packages +run on our servers and nothing else. At a first glance it might sound daunting, +but today’s hardware platforms ship some pretty useful security features. For +example, there is usually a separate hardware domain for key management, +cryptographic hashing, Platform Configuration Registers (PCRs), and digital +signatures. It is possible to measure code, data structures, and configurations +into a PCR before execution to form a hash chain, such that all initial system +states can be aggregated into a single value. The system’s boot process can be +aborted if a measurement diverges from the expected value, e.g., because the +boot loader did not enforce transparency logging as required by the top layer. +It is also possible to sign PCR values and attest them remotely. In other +words, if these features work we can prove to a third party how the system +booted. + +### Open source firmware and LinuxBoot +An immediate concern is that much trust is placed in the underlying hardware +platform. Naturally, it begs the question if such trust is misplaced. A + [talk by Ron Minnich](https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google) +brings you up to speed on why the answer is probably "yes". Let us focus on +solutions instead: open hardware, firmware, and boot loaders. It is paramount +that these components are vetted thoroughly in the open because they may +compromise the system + [while running or before it is even started](https://securelist.com/mosaicregressor/98849/). + +So, System Transparency implements a flavor of + [LinuxBoot](https://www.linuxboot.org/) +called + [stboot](https://github.com/system-transparency/system-transparency/blob/master/README.md#bootloader-stboot). +It can replace much of the later-stage UEFI components with a Linux kernel and a +user-land environment in Go, such that a subset of proprietary firmware is +removed in favor of an open source option that is safer and customizable. For +example, one possible customization is to enforce transparency logging as a +criteria to boot into the host operating system. It is possible to eliminate +UEFI all together by re-flashing the firmware with + [coreboot](https://doc.coreboot.org/) +and specifying stboot as a payload. The TL;DR is that coreboot is (mostly) open +source firmware that does the bare minimum hardware initialization. It was +recently + [ported to a modern server platform](https://mullvad.net/en/blog/2019/8/7/open-source-firmware-future/). + +### Set-up ceremony and tamper-evident hardware +Assuming an open platform that enforces transparency logging as described +above, you can be somewhat sure that said operating system packages run. The +problem is that you cannot easily know if that assumption is true. I am not +claiming that there is a slam-dunk solution here, but measures can be taken to +reduce the risk of a broken setup. For example, assemble and install the +platform while witnessed live by several independent parties that write down +and publish a log book of events that occurred: + "[neutralized the management engine](https://github.com/corna/me_cleaner)", +"added open firmware with checksum XYZ", etc. We can also define some physical +security boundaries that, if breached, automatically activate defensive +mechanisms that preserve the system’s overall integrity after setup. + +## Concluding remarks +The described System Transparency design shows how a service provider can +facilitate trust by engineering a system that is more trustworthy. I would like +to emphasize _more trustworthy:_ all of the applied techniques have merit on +their own, and if one part does not fit the use-case or current practice it +might be reasonable to cut it. For example, if you lease cloud servers that +only allow starting stboot from UEFI: so be it. Simply assume that there will +be no firmware and physical attacks for the time being. It is still a +significant improvement when compared to obscure operating system packages +since the attack surface and overall trust domain is reduced. +[The growing problem of malicious Tor relays in the cloud](https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac) +could benefit from such a solution because a class of real-world attackers would +not see any traffic (if enforced by Tor). As another example: suppose your +interest is mainly to harden your own internal infrastructure, and not so much +about making it transparent for everyone. It is not a strict requirement to put +the operating system package in the public, i.e., a hash is enough to convince +yourself that nothing else was allowed running. + +## Acknowledgments +Fredrik Strömberg provided valuable feedback on this story, which is sponsored +by my + [System Transparency](https://system-transparency.org/) +employment at Mullvad VPN. diff --git a/content/post/observations-from-a-trillian-play-date.md b/content/post/observations-from-a-trillian-play-date.md new file mode 100644 index 0000000..47b4f1d --- /dev/null +++ b/content/post/observations-from-a-trillian-play-date.md @@ -0,0 +1,130 @@ +--- +title: "Observations from a Trillian play-date" +date: 2020-11-23 +--- +Have you ever heard about + [Trillian](https://transparency.dev/) +in the context of transparency logging? Perhaps you view it as an integral part +of + [Certificate Transparency](https://certificate.transparency.dev/), +a solution for arbitrary transparency applications, or both. Even if you know +Certificate Transparency quite well the Trillian details might be a bit blurry +until you sit down and get some hands-on experience: at least that was the case +for me. Therefore, Trillian and I had a little play-date. I thought I would +share a few observations that in hindsight are obvious but at the same time +helpful. + +## Problem statement and overview +I agree with Daz Wilkin that + [it is somewhat daunting to get started with Trillian](https://medium.com/google-cloud/google-trillian-for-noobs-9b81547e9c4a). +Putting it all together involves many different components and configurations, +especially if you need the high reliability and scale that Trillian supports. It +does not have to be that complicated though. Trillian is pretty much a database +which includes an append-only Merkle tree: + +1. **Trillian log server:** exposes a gRPC API that is used by an +application-dependent front-end or so-called _Trillian personality_. Requests and +responses trigger operations on the underlying database, such as queuing new +data requests and assembling cryptographic Merkle tree proofs. +2. **Trillian log signer:** checks the database periodically and sequences it +into a Merkle tree. The term _log signer_ was confusing for me initially because +it is usually the front-end personality that adds externally visible signatures. +Therefore, I found it helpful to think of this component as a _log sequencer_. + +I will not talk much about the front-end personality. It is the part of Trillian +that you or your ecosystem has to implement. It will include definitions of +public endpoints, the data to be logged, who is allowed logging it, etc. + +## Trillian as a database abstraction +The simplest description of Trillian is probably as a regular database. You can +insert any item of your choice after serializing it as zeroes and ones, and come +back later on and retrieve it. In reality it is more accurate to say that +Trillian is hooked-up to a database, such as MariaDB using the schema over + [here](https://github.com/google/trillian/blob/master/storage/mysql/schema/storage.sql). +This means that before getting started a database must be configured such that +there is a record in the Trees table that identifies a particular Trillian +instance. + +``` +CREATE TABLE IF NOT EXISTS Trees( + TreeId BIGINT NOT NULL, + HashAlgorithm ENUM(‘SHA256’) NOT NULL, + SignatureAlgorithm ENUM(‘ECDSA’, ‘RSA’, ‘ED25519’) NOT NULL, + PrivateKey MEDIUMBLOB NOT NULL, + PublicKey MEDIUMBLOB NOT NULL, + ... +); +``` + +Initially I was confused by the public-key cryptography that is part of the +database schema: is it not the front-end personality that attaches signatures, +for, say, Signed Certificate Timestamps (SCTs) in Certificate Transparency? +Well, yes. But the scenario in mind here is that there might be a front-end +personality that runs in a different trust domain, such that the Trillian +back-end needs to sign some data to prove its origin. The front-end determines +what becomes externally visible regardless of if these signatures are used. + +New add-data requests are queued by the Trillian log server in an unordered +table of pending leaves. Each such leaf also has an optional appendix, which +allows extra data to be stored but without merging it into the Merkle tree. For +example, it might be reasonable to hold on to an associated signature if the +front-end personality requires that the data is signed as an admission criteria. + +## Trillian as a Merkle tree abstraction +The log signer sequences the pending leaf data periodically. By sequencing I +mean taking the unordered leaves that one or more log servers queued, and then +appending them to the current Merkle tree on specific indices. In other words, +not even the log servers know the index of an added leaf until it is merged. It +is important to keep in mind because several proposals in the past assumed that +Trillian logs are timestamp ordered, but strictly speaking there is no such +guarantee unless the front-end takes responsibility of sequencing (in which case +there is a specific pre-ordered Trillian API that can be used). + +The Merkle tree itself is viewed as many smaller sub-trees in the database, +where only the bottom layer of each sub-tree is stored physically. Any interior +node can be computed on the fly, which apparently + [saves up to 50% of space](https://github.com/google/trillian/blob/master/docs/storage/storage.md). +The log server accesses the database to interact with the sequenced Merkle tree, +e.g., to retrieve tree heads and build audit paths (hashes in the tree). As +such, there is no explicit communication between the log server and signer. + +## Trillian as an API +The final part of the puzzle is the interface that the front-end personality can +use while talking to Trillian. Fortunately, it is relatively straight forward. +You will only send requests and receives responses from the log server that +exposes a gRPC API. Possible requests and responses are documented + [here](https://github.com/google/trillian/blob/master/docs/api.md). +This is really the place to look if you want to know what will "just work". + +For example, you will notice that there is a `QueueLeafRequest` that takes as +input some data that goes into the Merkle tree and the leaf’s Appendix, as well +as an identity hash that tells Trillian what should be counted as a duplicate. +You may also take advantage of the built-in Trillian rate limiting by specifying +a custom `charge_to` string. You can think of this as saying "Dear Trillian, +this IP address requested to add a leaf and it is signed using a certificate +that ends in the following trust anchor". In response a resource exhaustion +error might be returned if too many requests were observed for a given quota +string. + +Other requests I would suggest you look into include retrieving a leaf, a signed +tree head, an inclusion proof, and a consistency proof. It goes a pretty long +way if you want to get what details are (not) in the front-end personality. + +## Concluding remarks +The view that Trillian is a database with an append-only Merkle tree is by no +means wrong, but it is also not a complete description. For example, there is +also a map mode that associates keys with values without being append-only. If +you look further into Trillian you will also realize that there are many details +that matter for deployment but not so much if we just want to get the hang of +things. For example, there is built-in functionality for running several log +server and signing instances, coordinating them, exporting health metrics, +choosing database back-ends, configuring rate limiting, and more. If that sounds +interesting you can get an enhanced intuition by reading the + [manual deployment scenario](https://github.com/google/certificate-transparency-go/blob/master/trillian/docs/ManualDeployment.md) +documentation for Certificate Transparency. + +## Acknowledgments +Fredrik Strömberg provided valuable feedback on this story, which is sponsored +by my + [System Transparency](https://system-transparency.org/) +employment at Mullvad VPN. diff --git a/content/post/trillian-log-sequencing-demystified.md b/content/post/trillian-log-sequencing-demystified.md new file mode 100644 index 0000000..bf1da6d --- /dev/null +++ b/content/post/trillian-log-sequencing-demystified.md @@ -0,0 +1,111 @@ +--- +title: "Trillian log sequencing: demystified?" +date: 2021-02-09 +--- +One way to view + [Trillian](https://transparency.dev/) +is as + [a database with an append-only Merkle tree](https://www.rgdd.se/post/observations-from-a-trillian-play-date/). +That Merkle tree is managed by a separate component called a log signer. It runs +in a dedicated process that basically merges pending leaves that have yet to be +incorporated into the Merkle tree. This part of the log signer is structured as +a sequencing job that runs periodically. I spent a few hours learning more about +the details and thought shared knowledge is better. + +## Problem definition and overview +Trillian’s + [log signer](https://github.com/google/trillian/blob/3ae67195ffd778d37275c6972445f4e7f9e21410/cmd/trillian_log_signer/main.go) +comes with a whole bunch of configuration options that are spread across several +different files. Some of these options are more difficult to grasp than others, +such as `num_sequencers`, `sequencer_interval`, and `batch_size`. I don't mean +difficult as in understanding that there may be several sequencers that run +periodically, but rather what that actually means in terms of concurrency and +how much can be sequenced per time unit. + +The short answer is as follows: +1. Regardless of how many sequencers you configure there will be no concurrent +sequencing of a particular Merkle tree. The number of sequencers is only +relevant if there are multiple Merkle trees. +2. The sequencer interval tells you how often the log signer wakes up to do a +sequencing job. It sequences no more than the configured batch size before going +back to sleep. If the interval elapsed already there will be no sleep. + +In other words, to avoid building up a large backlog you need to consider how +often the sequencer runs and how much work it is willing to do every time. The +longer answer is detailed below, and it includes a little bit of additional +context regarding what you may (not) do with these three parameters. For +example, the sequencer job is most reliable if it runs often over small batches. + +## Log signer +The most central part of the log signer is probably its forever loop. For +reference it is implemented by Trillian’s + [operation manager](https://github.com/google/trillian/blob/3ae67195ffd778d37275c6972445f4e7f9e21410/log/operation_manager.go#L110), +see the `OperationLoop` function. In a nutshell, the log signer wakes up, +performs some jobs, and goes back to sleep. Pretty much a busy working day! + +### Coordination +Before proceeding you need to know that a log signer may manage multiple +different Merkle trees. It might sound odd at first, but hopefully less so if +you think about the existence of transparency applications that use + [temporal sharding](https://www.digicert.com/dc/blog/scaling-certificate-transparency-logs-temporal-sharding/): +the split of one transparency log into multiple smaller ones so that the leaves +are grouped by, say, yearly relevance like 2020 and 2021. This allows parts of +the log to be retired as soon as they are no longer needed. You can also run +multiple different log signers to avoid single points of failure. At most one +log signer is responsible for a particular Merkle tree at a time though. This +requires coordination, which is one part of the forever loop. + +### Sequencing +The other part is log sequencing. After waking up once per interval as defined +by the configured `sequencer_interval`, the log signer takes a pass over all +Merkle trees that it manages. A sequencing job is scheduled for each Merkle tree +that the log signer is currently the master for. It is determined by an election +protocol which is used for coordination in the case of multiple log signers, +otherwise master is assumed as there is nothing to coordinate. Next, these jobs +are distributed to a number of concurrent sequencers that work on _different +Merkle trees_. This means that there is no concurrency whatsoever when _a +particular Merkle tree_ is being sequenced. Moreover, + [what is selected for sequencing](https://github.com/google/trillian/blob/3ae67195ffd778d37275c6972445f4e7f9e21410/storage/mysql/queue.go#L33) +is deterministic based on Trillian’s internal timestamp order and the number of +leaves that the sequencer is willing to process per job. + +In other words, there is no point setting `num_sequencers` higher than the +number of Merkle trees that you manage. You may set it lower, in which case at +least one sequencer will move on to a different sequencing job (and thus a +different Merkle tree) once it is done. Now it is also evident that the +configured `sequencer_interval` and `batch_size` determines an upper bound for +the number of writes per time unit. It is an upper bound because your hardware +might not be capable of handling, say, 10k writes per second. + +## Concluding remarks +When I noticed the `sequencer_interval` parameter I wondered if it could be used +to configure a tree head frequency, such that the Trillian front-end personality +would only see a fixed number of updates per time interval. For example, you +might want that because the + [second version of Certificate Transparency requires control over it](https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis-34#section-4.1) +and some gossip-audit models + [assume it](https://tools.ietf.org/html/draft-ietf-trans-gossip-05). +If not supported by the Trillian back-end, the front-end personality has to take +on the role. While it is trivial in the case of a single personality instance +(e.g., pick a tree head every hour), it might require some additional +coordination if there are multiple concurrent instances running. So, it would be +convenient if the _already coordinated_ log signer could enforce a tree head +frequency. + +In theory it is of course possible to set the sequencer interval and batch size +to accommodate both a frequency and an upper bound for writes per second. In +practice it is apparently recommended to use short intervals and batch sizes of +up to 1000 leaves. This recommendation involves quite a bit of nuance, and +relates to things like + [which back-end is used for the underlying database](https://github.com/google/trillian/issues/1845). +If tree head frequencies are generally useful it might land as a back-end +feature at some point. For now, it is better enforced by the front-end +personality. + +## Acknowledgments +This story is sponsored by my + [System Transparency](https://system-transparency.org/) +employment at Mullvad VPN. Martin Hutchinson and Pavel Kalinnikov provided +valuable insights as part of a conversation in the + [Trillian slack](https://gtrillian.slack.com). +Mistakes, if any, are my own. diff --git a/content/post/what-happened-at-ct-days-2020.md b/content/post/what-happened-at-ct-days-2020.md new file mode 100644 index 0000000..486bb5e --- /dev/null +++ b/content/post/what-happened-at-ct-days-2020.md @@ -0,0 +1,160 @@ +--- +title: "What happened at CT days 2020?" +date: 2020-09-14 +--- +This year’s + [CT days](https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/JWVVhZTL5RM) +were hosted remotely on September 8–9. The agenda covered a wide range of +topics, such as making CT more newcomer friendly, updating user-agent policies, +and what it takes to operate a log at scale. I do not intend to write about all +of it, and especially not every little detail. You will be brought up to speed +on some highlights and get further reading. All credit obviously goes to the +people who presented sessions on this material. + +## New community website +You might be familiar with the + [current CT website](https://web.archive.org/web/20200829193007/https://www.certificate-transparency.org/). +It is a little bit like an explosion of technical details and links from several +years back that, if you digest it all, tell you how Google’s CT project works. +This is not particularly welcoming for newcomers that need to grasp what CT is +today and how it fits into the broader picture of the web’s public-key +infrastructure. For example, CT is no longer Google’s own logging project, but +rather an ecosystem of different people and organizations that come together +with one mission: to detect maliciously or mistakenly issued certificates. This +happens to be the first thing you will find when browsing the + [new community website](https://certificate.transparency.dev/). +It is nifty looking, and I encourage you to browse it yourself. You will notice +that the origin story of CT and its broader context is described, which helps +the reader pick up the fundamentals from a combination of text and +visualizations. + + +**source**: https://certificate.transparency.dev/ + +[Ryan Hurst](https://unmitigatedrisk.com/) explained that we can think of the +new community website as a place where newcomers can be directed to understand +the value of CT and how it works. Moreover, it is our collective responsibility +to add anything that is missing and keep it up-to-date. Anyone can + [submit pull requests](https://github.com/google/certificate-transparency-community-site) +on GitHub. + +## Policy updates +I can second that it is not always easy to understand every nuance of CT +enforcement by different user agents. For example, I remember + [filing a bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1053971#c1) +not too long ago when noticing that Chromium (not to be confused with Google +Chrome) disabled CT by default. In the future there might be a separate and +lighter-weight Chromium CT policy that embedders could use as a starting point, +but for now Google’s policy will be shaped solely for Chrome. This is reflected +by the new CT policy website that is being drafted: the so-called + [Chrome Certificate Transparency Policy](https://googlechrome.github.io/CertificateTransparency/ct_policy.html). +[Devon O’Brien](https://twitter.com/modyoloN) appropriately described it as a +complete overhaul of what the current policy states and how these requirements +are framed specifically for enforcement in Chrome. + +The CT community website will link the updated CT policy once it goes live in +the near future. In the mean time, you can enjoy the draft and provide feedback +to the + [Chrome CT team](mailto:chrome-certificate-transparency@google.com) +or the + [CT policy group](https://groups.google.com/a/chromium.org/g/ct-policy). +The recommended starting point is the different states that a CT log can be in. +I am not going to detail it, but it was mentioned as a pro-tip in multiple +sessions. You will also notice that informative reference material was added, +with more to come as the broader community identifies components that are +unclear or missing. + +There are several policy changes in the midst of the above updates. While not +particularly huge, they are there and worth pointing out. All new CT logs must +be temporally sharded. A log that is temporally sharded accepts logging of +certificates that fall into a range of expiry dates. For example, a 2020-shard +would not accept certificates that expire in 2021. The status of sharding moves +from allowed to required, solving the issue of logs that grow forever and ever. +A log must additionally not return multiple different SCTs for a single log +entry, which solves undefined behavior in + [RFC 6962](https://tools.ietf.org/html/rfc6962) +that could lead to unverifiable SCTs in quirky corner cases. Note that a +certificate that passes the Google Chrome CT policy is now said to be CT +compliant. It is analogous to the current wording of a certificate being CT +qualified, and avoids confusion with CT logs that can also be qualified in the +browser. + +[Clint Wilson](https://twitter.com/clintw_) announced + [Apple’s intended policy updates](https://groups.google.com/a/chromium.org/forum/?oldui=1#!topic/ct-policy/JWVVhZTL5RM). +They are also working towards definitions in undefined scenarios, such as +expressing their policy in terms of days as opposed to months. The most notable +policy update (in my opinion) is that the SCT diversity and quantity assumption +for a CT compliant certificate is about to change. Currently, Apple considers a +certificate CT compliant if accompanied by two SCTs from any pair of CT logs. +Longer-lived certificates will require an additional SCT in the future, and log +operator diversity will be added as well. This reduces the risk that a once CT +compliant certificate will become non-compliant during its life time. The other +benefit is that no single log operator can issue a certificate’s SCTs, which +raises the bar towards unnoticed certificate mis-issuance. What it means that +two log operators are diverse (also known as independent) is somewhat +non-trivial: it can span many different dimensions, such as organization, +country, and infrastructural providers. Google’s + [updated policy for log operators](https://googlechrome.github.io/CertificateTransparency/log_policy.html) +will require a self-assertion that you are independent of all other log +operators. My best guess is that Apple will rely on something similar to define +log diversity. + +## Removing the one-Google log requirement? +Google Chrome currently considers a certificate CT compliant if it is +accompanied by two SCTs. One of these SCTs must additionally be issued by a log +that Google runs. If Google’s CT logs are operated in good faith, we can be sure +that there are no mis-issued certificates that go unnoticed. + +To state the obvious, the point of CT is not to trust that Google keeps the +wider web safe from certificate mis-issuance. The current set-up is in fact +quite error-prone: sub-optimal trust assumptions aside, a Google outage would +essentially disable issuance of new CT compliant certificates on the web. Devon +O’Brien expressed a desire to remove Google from the critical path of +certificate issuance, and what considerations that need to go into such a +decision. The major part is that Google must accept that they lose their +privilege of observing all issued certificates up-front, which provides +significant proactive security for Chrome users but might impend broader +user-agent adoption. The result of such a change is that SCTs must be audited +reactively in the background from many diverse vantage points, such that +mis-issued certificates get noticed without the one-Google log policy. + +[Chris Thompson](https://notyetsecure.com/) presented Google’s plans on + [opt-in SCT auditing](https://docs.google.com/document/d/1G1Jy8LJgSqJ-B673GnTYIG4b7XRw2ZLtvvSlrqFcl4A/edit). +The basic idea is to submit a random subset of SCTs to a Google-operated CT +auditor. If an SCT is encountered that Google does not know about, that can be +investigated further by challenging the issuing CT logs to prove certificate +inclusion. The reason why this requires opt-in stems from the fact that the user +is essentially sharing a random subset of its browsing history with Google. You +might wonder who would opt-in for that, but it actually fits pretty well into +the existing Safe Browsing Extended Reporting (SBER) programme. My largest +concern is that opted-in users might be identifiable, and in that case the rest +of us could still be attacked without high likelihood of detection. + +[Sarah Meiklejohn](https://smeiklej.com/) presented a follow-up session on +privacy-preserving SCT auditing. It could be described as partial highlights of +a systematic literature study that considered 15 different proposals against the +following criteria: + +1. **Functionality**. Does it work and in what threat model? +2. **Privacy**. What information do which parties learn? +3. **Client-side performance**. Bandwidth, computation, and storage? +4. **Latency**. How much is added, if any? +5. **Server-side infrastructure costs**. What needs to be changed or added? +6. **Threat model**. Mainly in terms of which parties need to trust each other. +7. **Non-Google deployability**. Can it be deployed without Google-scale? +8. **Near-term deployability**. Can we roll it out sooner rather than later? + +A subtle message is that a proposal without a third-party CT auditor is +incomplete. I share this view because we cannot expect an end-user to take any +reasonable action if log misbehavior is suspected. Therefore, it is not just +proof fetching that needs to be private: also the process of reporting issues. + +## Acknowledgments +Thanks to everyone that contributed to CT days 2020, both in terms of +organization and putting in the actual work that the different sessions +presented. A detailed summary and follow-up discussion might appear on the + [CT policy list](https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy). +Fredrik Strömberg provided valuable feedback on this story, which is sponsored +by my + [System Transparency](https://www.system-transparency.org/) +employment at Mullvad VPN. |