[dns-operations] DNS over TLS: slowly happening

[John Todd]

On 28 Jun 2018, at 1:59, Hellqvist, Björn wrote:

[snip]
>>
>> I completely agree with Bert and John here. The move to browsers 
>> doing their
>> own DNS directly using DoH (probably to preferred providers) is 
>> happening
>> whether we like it or not. It is a hard argument to persuade users to 
>> switch
>> back to an unencrypted transport to their ISP when browsers are 
>> ‘protecting
>> their DNS’ (or however it is sold).
>
> So if a browser do a DNS-over-HTTPS and utilize say google and the 
> customer is logged in on a google account.
> Then it could probably fall under GDPR/EPR, since it can be tracked to 
> a real person, right?
> And GDPR/EPR can be quite a mess.

Agreed that it is a bit of a policy mess for any organization that has 
data about IP addresses in some way that is possible to associate 
“natural persons” with data being collected. ISPs are in the same 
category - there is a relationship (typically due to payments required) 
between a household or person and the data that is visible on a 
particular circuit, or service such as DNS resolution. This inescapable 
pre-existing knowledge within the organization makes DNS an automatic 
GDPR landmine.

Not all third-party DNS recursive resolver providers have extra data 
with which they can correlate natural persons to DNS lookups. Almost all 
say they do not create such correlations even if they are able to, but 
ability and intent are often difficult to separate over time and 
commercial pressures. (I am admittedly biased on this point, speaking 
from the perspective of a non-profit.)

Given the two points of GDPR-entangling ISP correlation ability, and the 
drive of third-party DNS providers to NOT have that correlation ability, 
it may be the case that some ISPs may find that offloading DNS 
resolution to external organizations who are naturally less informed 
about clients may remove some GDPR headache from their long list of 
compliance systems that they must manage. With encryption of the DNS, 
this outsourcing becomes even more useful as it is then possible for the 
ISP to claim it is not even possible to intercept the DNS lookups, 
further diffusing the points of pressure for any interest in that data 
from a policy compliance view. I have spoken to a few ISPs who have been 
quite interested in and have implemented this GDPR offload model, but of 
course this will vary significantly between organizations and their 
perceptions of the risks and payoff of outsourcing DNS.

If the ISP outsources DNS, then one the last remaining privacy windows 
that the ISP has open is client traffic SNI, but hopefully that will 
change in the future. If and when SNI becomes invisible, then I see very 
few places where the transport provider has the opportunity to 
understand the content of traffic from end users except for IP address 
destination, which is becoming less useful as well with CDN delivery of 
data. I believe this is a good thing.

> Also I do not say we should not do privacy on DNS. DNS-over-TLS might 
> not even be a real problem and we might even consider implementing it, 
> just for fun.
> We are no strangers when trying out new features, we tried to 
> implement DNS Cookies last autumn. But the real world is not really 
> ready for it.

I’m sure you’ve seen the DNS Camel 
(https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01) 
talk and associated efforts. There is lots of straw yet to be added to 
the camel’s back, mostly from an operational requirements perspective, 
though I’m not a big fan of adding any more protocol features due to 
the load that already exists. After the straw gets added to the DNS 
Camel and is turned into code, then that turns into straw on the DNS 
operator’s backs when we try to find out if these new shiny features 
or standards will work in the unfriendly wild and at scale. Not 
implementing them means growing numbers of complaints in the support 
mailbox, or exposure to new fault cases (hello, DNS rebinding attacks!) 
So we have to balance what is desired, what is useful, what is possible, 
and what we can get coded. Very rarely is there a balance between those 
things, though often features or functionality that is imbalanced in one 
of those categories makes its way into production (“I can code this, 
no problem!”, “This big paying customer needs this feature.”, 
“This patch keeps us from being DOS’ed into oblivion.”)

DNS-over-TLS and DoH seems like a rare case where this balance might 
work out, though they are both very heavy straws from the operator 
viewpoint once at scale. Again, for organizations whose only job is to 
do recursive or authoritative DNS this is an expected burden, but ISPs 
or enterprise operators may find the increased complexity of running DNS 
something they are less inclined to want to do if they intend to stay 
current with best practices.

> There are a lot of old Authoritative DNS installations out there. The 
> oldest we got in contact with had a 17 years old MS DNS installation. 
> (They have now changed to BIND after we pointed this out)

We have also found and in some cases communicated with operators of 
authoritative MS or BIND implementations were double-digit years old and 
which caused profoundly subtle and frustrating problems with resolution. 
Those (anecdotally) are becoming fewer in number, even in the last year 
there seems to be a much lower incidence of needing to do gymnastics to 
solve auth server problems, though there are of course still many new 
methods of broken-ness that continue to appear.

I am encouraged by the progress made in encryption methods for stub 
resolvers since that is almost all “new” code to be written. This 
means that at least for a little while both the servers and clients will 
be in sync with features and functionality because of their newness and 
small community of authors and cross-testing that will be performed. 
Give it a year or two, a dozen implementations, and some vendor 
embracing-and-extending and then we’ll find divergence and we’re 
back on the camel ride. Enjoy the golden time now, I suppose, but this 
is the way of standards.

> But it would have been good to see some numbers on its limitation. And 
> it might be that we do not find the problems until it is implemented 
> and there is substantial volumes.
>
> Thanks Sara, both presentations gave some inputs.

Thanks from here too - data is fantastic!  We’re happy to assist with 
giving access to data for our existing production DNS-over-TLS traffic 
(and any other encryption forms that we support) in any way as long as 
we can maintain end-user privacy and operational envelope requirements.

JT