Hi Mukund-- On Tue 2018-12-11 11:13:39 +0530, Mukund Sivaraman wrote: > During last night's meeting, there was talk about use of a split-cache - > one with answers learned from plain transports and another with answers > learned via secure transports.
I think i was the one that mentioned that there *could* be a security or
privacy issue there. fwiw, i really want the answer here to be "don't
worry about it, use a single cache", because that makes implementations
significantly easier.
In the long run, there might even be privacy or security tradeoffs here,
and we might decide that they're prices worth paying for the additional
implementation simplicity -- i don't know.
I just want to try to ensure that we've at least thought about some
potential downsides and mapped them out.
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).
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
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
