Re: [Add] What to do in this potential working group

[Jari Arkko <[e-mail]>]

Thanks for your email, Ted. Your questions are useful and can help us understand the situation better.

> The third threat model is that the use of a single large common recursive resolver mitigates against attacks which track resolution events at the authoritative servers (since there are common cached replies), but results in that large common recursive becoming an attractive target for unsavory business practices, court orders, and infiltration attacks.  Because of browser fingerprinting techniques the available information may be larger for DoH than it would be for other clients.
> 
> Your concern is that using DoH as a response to the first and second attacks is increasing the risks related to the third.  Is that approximately correct?

Yes, but only approximately. There are multiple factors at play, one is use of encrypted transport and the other one is the degree of centralisation of users’ queries. And some other factors, such as to what extent various parties can change the situation, what the majority of Internet users will be doing based on defaults, etc.

But the main issue that I have is centralisation of DNS queries to an administratively single entity. This is actually an issue even without DoH, but the potential introduction of new defaults and DoH makes the situation more acute.

I do want to underline that there are obviously great benefits with DoH, and even some benefits with centralised DNS setups. But I’m concerned that if we look from a privacy perspective, the default-to-quad-n setup seems… shall we say suboptimal.

Let me make this a bit more personal. I live in Finland, where there is in practice no or very little DNS filtering. My favourite privacy-sensitive browser will today ask my network/my ISP network for DNS resolution services, and the entire process (at least if cached) is local within organisations that I have a contractual relationship with, and who I trust. Now, imagine that the next version of the browser comes with by-default quad-n/doh setting, and now the browser will be contacting a different server that I have first of all no relationship with, and who is very likely either outside Finland or at least administratively controlled by an entity residing in a five eyes country that Snowden revealed performs extensive and indiscriminate surveillance. I know personally some of the people who run some of the global DNS services and have the highest trust on them. But, even they aren’t immune to laws, governments, and various surveillance techniques. I will have to assume that my queries are being tracked. On *every click* that I do on my browser.

You can imagine that I don’t like that situation. I can of course change my settings, but what about my mom or the million other people living nearby? I would consider such browser behaviour essentially spyware. I realise that I’m using a heavy word; I don't use the word lightly but I think that’s a very reasonable description of what’s actually happening.

But onwards to happier things.

First, wouldn’t it be great if I could get DoH to work with my ISP? What other things would that require than my ISP’s action?

> If so, I think there are practices that we might develop and recommend (e.g. selectively sending queries to different trusted resolvers)

Indeed.

I don’t think the the only answer is default quad-n (or doh). I suspect that there’s others things that could be pursued, if one wanted to preserve privacy, *not* collect huge amount of data, and still want to provide better confidentiality. Starting from not sending to one place but say a collaborative large-ish group of services. Or not sending queries to overseas entities to begin with :-)

> and some of those may also touch on the split DNS issue.  My modest experience in this realm suggests, though, that experiments are the only thing that would tell you the impact of those practices on latency, correctness, and leakage.  So I'd want some indication that folks are willing to run those experiments before taking on that work.

I think step one is recognising that we have a problem. And having willingness to care about that problem. Step two is thinking about potential approaches to mitigating problems. There may be experiments to be run as well in step three, would be happy to see that. At least if that was not happening as a side distraction to keep as IETFers happy while the business world is busy switching the entire Internet DNS to a centralised model...

Note also that my particularly worry is about privacy and surveillance, and I think the filtering/control/split DNS etc issues are complex and will take some time. I think.

Jari