Public verification of log behaviour - obtaining proofs

47 views
Skip to first unread message

Eran Messeri

unread,
Feb 23, 2017, 2:32:24 PM2/23/17
to tr...@ietf.org, certificate-...@googlegroups.com
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


Reply all
Reply to author
Forward
0 new messages