Hi Daniel

On Thu, Dec 13, 2018 at 02:32:41PM -0500, Daniel Kahn Gillmor wrote:
> The degenerate scenario i'd painted on the call was:
> 
>  * consider a DPRIVE-capable DNS resolver; for whatever reason, only a
>    single request has been made to it since it booted.
> 
>  * a new cleartext (non-private) request comes in for foo.example, and
>    it does the lookups it needs to do, all in the clear. (private
>    queries to authoritatives would have worked, but they weren't tried
>    since the initial request was in the clear anyway).
> 
>  * a subsequent private request comes in to the resolver, and the
>    resolver responds without doing any upstream lookup.
> 
> in this scenario, a passive observer of the resolver's traffic can infer
> that the private query was likely also for foo.example (or at least, for
> one of the names that needed resolution in order to get an answer for
> foo.example, like NS records).

Ah.. I follow it now, and why you think it is a leak. :)

A resolver can respond to several queries without performing any
upstream queries. As an example, take RFC 6761. Nothing can be inferred
about a query simply because it didn't result in resolution.

> 
> So this is a privacy leak, which could be mitigated by treating the
> cache of RRs-accessed-in-the-clear as invalid for retrieval of the
> private query unless private authoritative DNS is confirmed to be
> unavailable.
> 
> There might be other effective mitigation besides a split cache,
> though.  for example, preferring private queries upstream in the first
> place for every query might offer some mitigation.
> 
> what do you think?
> 
>       --dkg

                Mukund

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to