Subject: [Trans] Public verification of log behaviour - obtaining proofs

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

I’d like to overview a few options for clients to obtain inclusion proofs
of log entries (each comprising of the corresponding SCT’s timestamp +
certificate) in a privacy-preserving manner.

The naive approach, of contacting the CT log itself (or a proxy), discloses
to the operator of the service the certificates each client (as defined by
IP) observed.

Option 1: DNS-based protocol [1].
Clients perform two types of queries, under this protocol:
* Getting the index of an entry.
* Getting an inclusion proof for entry with the given index.

This protocol preserves the client’s privacy by using the client’s
recursive resolver to proxy the request (rather than directly connecting to
a service) - full privacy analysis is at [2].

An upside of this protocol is that responses to queries generated under
this protocol are constant and can be cached infinitely - an entry’s index
will never change, as well as the inclusion proof from a particular index
for a particular tree size.

This is the approach the CT team and Chrome team at Google are working on
implementing - currently DNS queries are authoritatively resolved by a DNS
front-end of the CT log mirror operated by Google. The intent is to measure
success rates and validate correct operation under most scenarios, then
standardize the protocol.

Option 2: SSL Proxy for log traffic.
Clients connect to a proxy that will relay the TCP connection to the log
(much like SOCKS5), but perform an SSL handshake with the log. Since the
connection is coming from the proxy, the log will not learn which clients
observed which certificate. As the connection is encrypted, the proxy will
not learn which clients observed which certificates.

One downside of the protocol is that responses are not cacheable by the log
/ proxy (at least not with a naive implementation). It should be noted that
clients only need to fetch an inclusion proof once per observed
certificate, not once per connection, and that information can be cached on
the client.

The other downside, and the reason we didn’t implement this approach at
Google, is that collusion between the proxy operator and the log operator
could easily correlate requests to the proxy with requests to the log and
de-cloak clients.

Note the underlying assumption of clients having up-to-date Signed Tree
Heads, provided to them by the UA vendor. While the original design called
for clients obtaining STHs themselves, having UA vendors push down STHs
improves the scalability aspect and does not change the threat model (since
clients already trust the UA vendor). If anything, it serves to guarantee
all clients have the same view of the tree, making it harder for the log to
present split views.

I’ll post separately about dealing with the result of an inclusion proof
check.

Eran

[1]
https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md
[2] https://www.ietf.org/mail-archive/web/trans/current/msg02617.html