Subject: [Trans] Privacy analysis of the DNS-based protocol for obtaining inclusion proof

From: Eran Messeri <[email-masked]>
Date: Thu, 12 Jan 2017 14:40:25 +0000

All,

We're soliciting feedback on the privacy implications of using the
DNS-based protocol for obtaining inclusion proofs from mirrors of CT logs (link
to protocol description
<https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md>
).

I've attempted a privacy analysis, together with Daniel Kahn-Gillmor, Sara
Dickinson, Melinda Shore, in the following document:
https://docs.google.com/document/d/1DY2OsrSJDzlRHY68EX1OwQ3sBIbvMrapQxvANrOE8zM/view

The goal is to get community feedback on the correctness and completeness
of the analysis, so that the privacy implications aspect of the protocol is
publicly reasoned about and documented, and each CT client (in particular
User Agents) could make an informed choice on implementing the protocol.

Please comment on the trans IETF mailing list, not the document itself.

Thanks,
Eran

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 12 Jan 2017 09:42:14 -0800

I. Under the "Certificates for hosts whose address was not obtained via
DNS lookup" section, a few scenarios come to mind:

1. The host was accessed by IP address.

2. The hostname was resolved by a SOCKS proxy server.

3. The hostname was resolved using DNS, but the local resolver forwarded
the query directly to a local authoritative server instead of recurring
via the root.  This scenario is probably quite common in corporate
networks.

II. Another privacy consideration is that the log DNS frontend learns
the IP address of the recursive server, which in some cases may uniquely
identify a person.  This is not an issue if the recursive server is
shared between many people, as a large ISP's would be, but what about
folks running their own recursive servers?  Some home routers run a DNS
server - are they recursive or just forwarding?  Even if a recursive
server is shared, if it's not shared with enough people, it may be
possible to identify a person by correlating requests made at around
the same time.

I think more data is needed before concluding that this
approach provides the desired privacy.  Could Chrome run an
experiment which resolves a DNS record for a hostname of the form
<client-public-IP-address>.<test-domain>, and measure how many
different <client-public-IP-address>es per recursive server are
observed over various time periods by the authoritative servers
for <test-domain>?

Regards,
Andrew

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Jan 2017 09:58:05 -0800

(Removing cross-posting)

As a minor quibble, and for sake of distinction, the W3C Resource
Hints ( https://w3c.github.io/resource-hints/#resource-hints ) that
describes how browsers perform things like preconnect and prefetch
makes efforts to distinguish between "dns prefetch", "preconnect", and
"prefetch" - each representing different parts of the connection
establishment and resource fetch. If your goal is to contextualize it
in the context of user agents, then it may help to note the
differences.

It's also unclear whether you're looking to do the privacy analysis
solely in the context of the proposal, or considering it's integrated
nature. I highlight this both because of specs like
http://wicg.github.io/reporting/ (which also involve queues and thus
the cross-resolver issues), Service Workers (
https://w3c.github.io/ServiceWorker/ ) which can enqueue things, and
more holistically, the implications of documents such as
http://www.chromium.org/Home/chromium-security/client-identification-mechanisms

On Thu, Jan 12, 2017 at 6:40 AM, Eran Messeri <[email-masked]> wrote:
> All,
>
> We're soliciting feedback on the privacy implications of using the DNS-based
> protocol for obtaining inclusion proofs from mirrors of CT logs (link to
> protocol description).
>
> The goal is to get community feedback on the correctness and completeness of
> the analysis, so that the privacy implications aspect of the protocol is
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Tom Ritter <[email-masked]>
Date: Thu, 12 Jan 2017 12:48:09 -0600

On 12 January 2017 at 08:40, 'Eran Messeri' via
certificate-transparency <[email-masked]>
> Please comment on the trans IETF mailing list, not the document itself.

Awesome, thanks for this Eran!

I can think of a few things that are probably worth adding.

I second Andrew's comments about uniquely identifying a user (although
user clustering, especially with businesses seems even more likely and
similarly problematic.)

It seems like query clustering (by resolver) is possible - similar to
visited hosts vs resolved hosts the DNS operator can make inferences
about which queries from a resolver come from the same client. (I'm
not sure this is terribly useful, the most reliable attack I could
imagine is traffic confirmation like "They visited
besthomesinseattle.com and then 221springstseattle.com".)

-tom

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Jan 2017 12:32:54 -0800

> 1. The host was accessed by IP address.

To expand on this: Your assumption/model here is that the DNS resolver
learns this information, but they are not otherwise on-path, correct?
That is, imagine a user using a resolver of 8.8.8.8 - presumably,
Google's not malicious, but this would disclose to them IP-based
connections?

> 2. The hostname was resolved by a SOCKS proxy server.

This is only relevant to clients that support SOCKSv5-based
resolutions, right? And is this just a specialized form of "using a
different resolver"? Or do you think it's distinct?

> observed over various time periods by the authoritative servers

In expanding on your hypothetical test, what's the outcome or desired
property that you're trying to measure? I imagine a total number of
distinct IPs is itself not meaningful to such an analysis.

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 12 Jan 2017 14:28:40 -0800

On Thu, 12 Jan 2017 12:32:54 -0800
Ryan Sleevi <[email-masked]> wrote:

> > I. Under the "Certificates for hosts whose address was not obtained
> > via DNS lookup" section, a few scenarios come to mind:
> >

It would disclose the IP-based connection to the resolver, the log's DNS
frontend, and any eavesdropper along the path taken by the DNS query.

Normally when you initiate a connection based on IP address, no one learns
about it except for nodes along the path to the endpoint (assuming no
OCSP), and that path might not even traverse the public Internet.

> resolutions, right?

Also clients that support SOCKS4a.

> And is this just a specialized form of "using a

It could be seen as a specialized form of using a different resolver.
(To be pedantic, the hostname lookup is not performed by the UA and the
SOCKS server might not even use DNS, which is why it seemed to fit better
in the "not obtained via DNS" category.)

> distinct IPs is itself not meaningful to such an analysis.

We would want to know the number of distinct <client-public-IP-address>es
per DNS resolver IP address that sends a DNS query for <test-domain>.
The desired property is that this number is high for most DNS resolvers,
as this indicates that there is privacy value to using DNS instead of
fetching inclusion proofs directly from logs.

Regards,
Andrew

---

From: Eran Messeri <[email-masked]>
Date: Wed, 18 Jan 2017 10:56:43 +0000

Thanks all for the feedback, which I've attempted summarizing below, let me
know if I've missed something:

- Navigating to hosts by IP which have SSL certificates logged in CT logs
would now be disclosed to the UA's resolver. A mitigation could be not
looking up inclusion proofs for these if data shows this is a common use
case.

- Inclusion proof queries may end up going through different resolvers if
there's a local authoritative resolver for the domain in question: The same
scenario mentioned in discussions about name redaction, where internal
host-names (which are resolved by a local, authoritative resolver within an
organization's network boundary, not resolvable outside of it) are secured
by public CA certificates. In that scenario, it seems to me the inclusion
proof queries would originate from a small number of recursive resolvers
within that organization, given UAs outside the organization's network
shouldn't ever observe these certificates.

- Unknown how many IPs are served by recursive resolvers, as some recursive
resolvers may serve very few clients or the possibility of user clustering:
That's no worse than the current system, isn't it? I believe (hope!) home
routers run forwarding resolvers that'd forward to the ISP's DNS servers,
so only users who run their own recursive resolvers are affected, and what
they disclose to the authoritative resolver for inclusion proof queries is
the same as what's disclosed to root servers.

- Privacy analysis in the context of client identification mechanisms:
Something I definitely intend to look into, once there's consensus that the
privacy analysis for this protocol is accurate (no point evaluating it in
the context of other client identification mechanisms beforehand).

- Resource Hints: Not sure I see how that's related to this discussion.
Ryan, can you elaborate?

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 26 Jan 2017 16:37:47 -0800

> looking up inclusion proofs for these if data shows this is a common use

Meaning if it was an uncommon use case, the privacy leak is deemed
acceptable?

> - Resource Hints: Not sure I see how that's related to this discussion.

It was a terminology issue in the section "Disclosure of visited hosts vs
resolved hosts" - I was highlighting that the term "pre-fetch" in your
analysis, in particular, " This is less of an issue if pre-fetches actually
fetch content, rather than just looking up IP addresses for links/resources
the user is likely to consume."

As defined in Resource Hints (e.g. what UAs are doing), there's a
distinction between "DNS prefetch" (which appears to be how you're using
the term "prefetch"), "preconnect", and "prefetch" (which, in Resource
Hints usage, implies an actual fetch of the resource). So what you saw as
an ambiguous term ("prefetch" in your usage) is captured in Resource Hints
as two distinct terms ("DNS prefetch" vs "prefetch")

---

From: Eran Messeri <[email-masked]>
Date: Mon, 30 Jan 2017 14:44:54 +0000

> Meaning if it was an uncommon use case, the privacy leak is deemed
Not sure, TBH. The way I see it, extra code could be added to avoid
performing inclusion proofs in case the user has browsed directly to an IP
address - this complexity would be weighted against the commonality of this
use case (it could be that UAs will not deem this privacy leak acceptable
at all).

> as two distinct terms ("DNS prefetch" vs "prefetch")
Acknowledged, updated the document to use this terminology.