Reporting evidence of potential log misbehaviour

[Eran Messeri]

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