- Never allow any part of the computing systems you use to cache anything.
- Insist that everything in your life exist in a state of being functionally pure & stateless.
- Eliminate access to all sources of timing data.
- Make sure that all tasks are completed in a pre-determined fixed amount of time regardless of resource contention.
There are so many different side channel attacks, and the computing primitives & API choices we have been making for years make it challenging to build secure systems.
Caches are very deeply embedded in the culture of how computing is done. Making tasks take longer than strictly necessary to avoid leaking information goes against our instincts to optimize system performance.
It's going to take a lot of work and cost a lot of money to get software to a point where we aren't playing whack-a-mole with side channels.
More pragmatically, the current implementation of this technique can be dealt with by being very conscious of how much data your DNS resolver(s) are leaking & being conscious of how large the anonymity set is of the userbase of your DNS resolver(s).
If you limit DNS cache times and use blinding computation techniques to limit the identity information your DNS resolver has or retains about you, then DNS cookies can be largely mitigated. If you have faith that 1.1.1.1 is operated in the manner that Cloudflare claims, the measures they have taken go a long way to making DNS cookies unusable.
I also pointed out some additional specific mitigations when I reported this issue to the Chromium team in October 2015:
What if we designed the resolver to fetch many responses with the caching disabled and then caching all of them? In essence, force it to give you as many cookies as your desired anonymity set size and then sample this local store of cookies when calculating the response for the end client.
This would make it harder to build a fingerprint, especially if responses were sampled from a number of independent sources.
The next logical step in the arms race would likely involve fingerprinting systems using more bits than strictly necessary, and using error correcting codes - i.e. treat the sampling as "noise" to be overcome.
It seems both more straightforward and more effective to build recursion paths that you can trust aren't doing any intentional or unintentional caching.
This of course means the performance benefits of caching go away. This has been a theme in computing lately (i.e. CPU speculative execution leaks such as meltdown).
A recursor could be built which only uses each query response once, with prefetching used to reduce the performance impact.
However, the mere fact prefetched responses exist would also leak data.
> It seems both more straightforward and more effective to build recursion paths that you can trust aren't doing any intentional or unintentional caching.
I agree, but as you say, that will take quite some work and time to happen and will be costly. I was thinking of this as a possible temporary mitigation which would retain some benefits of caching. If it was made adaptive[1], it would also have the nice side-effect of being more resource intensive for those servers that attempt to use tracking.
[1] i.e. only fetch many responses if they appear to vary while doing a smaller number of "probing" requests. Continue fetching more responses for your local sample until they stop varying with some degree of confidence.
It would be difficult to differentiate between responses that vary due to load balancing and responses that vary due to active fingerprinting.
Even when a site only has a single physical location, load balancing might be done in part by having DNS randomly return one of many valid IP addresses. E.g. this is a behaviour supported by Amazon's Route53.
Larger sites frequently use a combination of anycast and DNS based routing to get packets to the closest POP. This introduces both (1) difficulty identifying when fingerprinting is occurring, and (2) still more opportunities for fingerprinting.
Most users will find it impossible to control which POP their packets get routed towards. For someone doing fingerprinting, it could be a very useful signal.
Third party DNS servers are helpful in one sense - you can share your state with other users.
Turning off EDNS with your own recursor won't really make much difference. Limiting the maximum cache length will help, but will also eliminate much of the benefit of having a local recursor.
The other issue with running your own recursor is nasty networks will transparently proxy DNS and you can end up using a cache you don't even know exists.
DNSCurve, DNSCrypt, and DNS-over-HTTPS solve one set of problems while introducing different ones.
Sharing a cache with other users introduces its own set of problems, e.g., cache poisoning. The problems that arise from shared DNS caches gave rise to "solutions" that in turn introduced further problems.
For transparent proxying, i.e., hotel internet, I use a local forwarder and a remote recursor listening on a non-standard port and it has worked flawlessly.
I prefer to serve static address info via authoritative DNS or /etc/hosts. I have other methods of getting DNS data besides querying caches. I have no need for DNS caches. Most websites I visit do not change addresses frequently. I also like to know when they change, if they ever do.
I have not experienced any problems with DNSCurve.
- Insist that everything in your life exist in a state of being functionally pure & stateless.
- Eliminate access to all sources of timing data.
- Make sure that all tasks are completed in a pre-determined fixed amount of time regardless of resource contention.
There are so many different side channel attacks, and the computing primitives & API choices we have been making for years make it challenging to build secure systems.
Caches are very deeply embedded in the culture of how computing is done. Making tasks take longer than strictly necessary to avoid leaking information goes against our instincts to optimize system performance.
It's going to take a lot of work and cost a lot of money to get software to a point where we aren't playing whack-a-mole with side channels.
More pragmatically, the current implementation of this technique can be dealt with by being very conscious of how much data your DNS resolver(s) are leaking & being conscious of how large the anonymity set is of the userbase of your DNS resolver(s).
If you limit DNS cache times and use blinding computation techniques to limit the identity information your DNS resolver has or retains about you, then DNS cookies can be largely mitigated. If you have faith that 1.1.1.1 is operated in the manner that Cloudflare claims, the measures they have taken go a long way to making DNS cookies unusable.
I also pointed out some additional specific mitigations when I reported this issue to the Chromium team in October 2015:
https://bugs.chromium.org/p/chromium/issues/detail?id=546733