By Monika Ermert, eLance Journalist - Adding personally identifiable information about your DNS customer – without him being really aware – is already applied by several DNS providers and baked in the DNS machinery by some vendors as an option.
At the most recent meeting of the Internet Engineering Task Force (IETF) in Prague, two proposals were made to make it a standard or at least to document it. What is notable is that the conflict over how to balance ease of use for operators versus added privacy for users on the net seems to take centre stage again, not only for the DNS, but also in the development of the new version of TLS, TLS 1.3 and the brand-new transport protocol Quic.
Both the proposal on “Client ID in forwarded DNS Queries” as well as the one for a new Meta Resource Record in DNS X-Proxied For (XPF) address issues of DNS network management. For Client ID, the authors, including David Lawrence from Akamai, underline the need to allow for “customized DNS responses” such as “parental control”, for example. For XPF, which has been written by authors from ISC and PowerDNS, the reasoning behind the proposal is the use of proxy devices and the negative effect of hidden source addresses for load balancing.
While XPF is intended to sit between the load balancer and the actual server and should, in theory, stay in the server's premises, Connection ID would sit between the end-user machine and a provider. The latter, as Stéphane Bortzmeyer (DNS expert from Afnic) explains, could be considered as much more dangerous. Nevertheless, both proposals go in one direction: both add meta-data to DNS queries and enable pervasive monitoring.
The discussion over these drafts certainly clarifies that adding personally identifiable information form IP addresses to MAC addresses or, as the Client ID draft proposes, “other defined Identifier-type values”, is regular practice for some operators including vendors like Cisco, Nominum or PowerDNS. They would therefore like to get a standard document approved – or even an informational document with an IETF stamp. Yet many from the DNS ccTLD community and the privacy expert camps are worried that this will simply counter the efforts to make the DNS more privacy-friendly and privacy-legislation compliant.
The fight on how to balance ease of use for operators versus better privacy protection is by no means reserved to the DNS community. It seems to be a common trend at the IETF these days, with the TLS WG and the Quic WG that were both locked in duels on these positions for extended parts of their sessions in Prague.
For the TLS WG, a proposal to consider a static Diffie Helman key to allow data centre operators to capture all data traffic live for monitoring reasons is the topic of an epic fight. As the authors admit, including former IETF Chair Russ Housley, Security Expert Matthew Green and former IETF Internet Area Director Ralph Droms, the proposal would break forward security, one of the very features hailed as making connections more secure. “It's wiretapping”, ranted Stephen Farrell, the former Security Area Director who collected a long list of arguments objecting to the IETF even continuing to discusses the proposal.
The WG on the new transport WG Quic also entertains a passionate discussion about how much information on Round Trip Times of packets should be exposed in order to help operators to manage their network traffic.
Looking at all three discussions, Sara Dickinson (Sinodun) said that she had never seen as much tension over the “balance” question in an IETF meeting.
Everything over Quic, DNS over everything
The quick development of Quic as a new transport protocol remains one of the spotlight topics of the IETF, since the changes it could bring are massive. Enthusiasts hope (and those more sceptical do acknowledge as well) it could become a successor protocol for TCP on the net. Given the structure, while based on UDP, Quic includes TLS features and will provide seamless, faster and be more privacy-friendly because of encrypted transport for web applications.
Zero-Roundtrip encrypted connection establishment on re-connections, multiplexing, plus an advantage over TCP through killing head of line blocking are the features enthusiasts never cease to promote. While Prague saw a lot of time spent on the topic of how much information on Round Trip Time should still be made available for the operators from the encrypted stream, the WG nevertheless did move forward a bit on their issue list, Jana Iyengar said after the two sessions. The WG is pushing ahead feverishly, with intermediary meetings between every official IETF meeting and a first interoperability test of five implementations, including Google, Mozilla and Microsoft, was conducted during the IETF Hackathon.
The push for Quic can be read from a first documented proposal for DNS over Quic, presented by Christian Huitema (Microsoft) during the Prague meeting. In the DNS community, there is some concern over Huitema's proposal, which is premature, given that Quic is not fully specified yet. Some also fear that the effort for the new transport protocol could derail other current efforts to move to DNS over TLS. A dozen recursive servers are now available for testing DNS over TLS and more are to come, said Dickinson in Prague. She also committed to soon be able to present an easy to use GUI for the Stubby Client, a DNS over DNS stub resolver client.
At the same time, Dickinson co-authored the DNS over Quic draft. However, that was not to question DNS over TLS, she underlined. The logic was more that Quic could allow for a quicker securing of the recursive to authoritative server path. The implementation of DNS over TLS was nevertheless indispensable for now, because Quic could still be years down the road. Yet, having implemented DNS over TLS would also make transition to Quic easier, she thinks.
There are also those who think that there is no need to wait for changing transport for DNS at all. “Let's just move to DNS over HTTPS” is a proposal presented by Paul Hoffman (ICANN) in Prague. While he focuses a lot on allowing HTTP and application developers the full range of DNS services, including DNSSEC, SRV or DANE, there certainly are those that see the effect on privacy when the newest version of HTTP2 would be chosen and TLS would be mandatory again. DNS over TLS, DNS over Quic, DNS over HTTPS – what should you chose? That depends pretty much on who you are, Hoffman and others say.
Stay tuned for a full version of the IETF99 CENTR report, which will be published by mid-August!
