Subject: [Trans] Reporting evidence of potential log misbehaviour

From: Eran Messeri <[email-masked]>
Date: Thu, 23 Feb 2017 11:44:29 -0800

To complement my other post about methods for obtaining inclusion proofs,
I've listed some thoughts about coping with failure to obtain an inclusion
proof. Note that this is not a concrete work plan, and does not represent
conclusions reached with the broader CT & Chrome teams.
Feedback is most welcome.

Under the assumption of the current deployment of 6962, in particular:
- Clients get SCTs (without inclusion proofs).
- Clients periodically receive STHs from a the UA vendor (which acts as a
trusted auditor).

The problem is:
How can log misbehaviour, observed by some clients, can be published to
other parties? More concretely, how can clients, in possession of a
suspicious log promise, make other parties aware of this promise?
Particularly, SCTs that could not be audited successfully (“suspicious”
SCTs).

Assumptions:
* The client trusts the UA software vendor (which is already the case).
* Same incident response model as for misbehaving CAs: Clients can only
disclose evidence, but not take local action, and rely on the managers of
the root store program for remediation.

Approaches for solution:
(1) Disclose “suspicious” SCTs to the UA vendor.
(2) Disclose “suspicious” SCTs to the website owner (or a chosen collection
service).
(3) Privacy-preserving proof of log misbehaviour.

(1) Is the most trivial action for a client to take, but has to be balanced
against privacy implications (of disclosing part of the browsing history).
For example, a client could only disclose SCTs from a certain log for which
it failed to get an inclusion proof, while at the same time being able to
obtain inclusion proofs for other SCTs from the same log. The heuristics
for determining when to disclose SCTs to the trusted auditor, or when to
suggest so to the user, should be based on real-world data of success rates
for obtaining inclusion proofs, which is the motivation behind deployment
of the DNS-based protocol.

Option (2), of reporting SCTs to the originating website or a collection
service nominated by the website has better privacy properties, as
information about observed certificates + SCTs is only reported to the site
from which it originated. This method is specified in the Gossip document.
It does require website participation, but does not require websites to
make security decisions (as observed SCTs can be passed along to monitoring
services).

A third option is a privacy-preserving proof of log misbehaviour - there's
academic work in the area which I hope to be able to share soon, but can be
implemented on top of RFC6962 (and would be simpler to implement on top of
6962-bis). In this option, there would be a proof, signed by the log, that
it cannot fulfil a commitment to incorporate an SCT. One variant would not
disclose the SCT at all, and another one would disclose the timestamp from
the SCT, allowing black-listing of bad entries.

Note, that all of these options would work if clients receive embedded
inclusion proofs + STHs.

Reporting back to the UA vendor implies trust in the UA vendor to take
action. To add transparency to the system and prevent the option of a UA
vendor denying having received potential evidence of log misbehaviour, all
such evidence (as well as the view of logs the UA vendor sends to its
users) can be logged in a verifiable data structure.

The problem of global consensus on the state of CT logs (i.e. among UA
vendors, for example), is a much broader one that may be tackled by the
“Internet-level Consensus” list.

Eran