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? On Thu, Jan 12, 2017 at 10:28 PM, Andrew Ayer <[email protected]> wrote: > On Thu, 12 Jan 2017 12:32:54 -0800 > Ryan Sleevi <[email protected]> wrote: > > > On Thu, Jan 12, 2017 at 9:42 AM, Andrew Ayer <[email protected]> > > wrote: > > > 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. > > > > 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? > > 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. > > > > 2. The hostname was resolved by a SOCKS proxy server. > > > > This is only relevant to clients that support SOCKSv5-based > > resolutions, right? > > Also clients that support SOCKS4a. > > > And is this just a specialized form of "using a > > different resolver"? Or do you think it's distinct? > > 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.) > > > > 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>? > > > > 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. > > 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 > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
