On Thu, Feb 23, 2017 at 2:31 PM, Eran Messeri <[email protected]> wrote:
> 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 find this option much more appealing than the DNS option. With Mozilla hat on, I would probably be willing to support deployment of such a service. It doesn't rely on the DNS to provide privacy properties (something the DNS is not designed for). Note that this solution still allows the log to associate all of a user's queries (at least all on the same TLS connection); it just doesn't give it an IP address to associate to this set. So I would be slightly happier queries were encrypted independently, e.g., using S/MIME or JWE. That will cost an extra X25519 operation per query and some extra engineering effort, but seems probably worth it for the additional privacy. Assuming that logs are going to want to use some sort of caching layer / CDN, that leaves you with kind of a four-level system: Browser --- Proxy --- Cache --- Log ... where the query encryption goes from browser to cache. This is like 2/3 of Tor, but should be a little easier to build :) --Richard > > 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 > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
