The Internet Engineering Task Force wants to secure DNS metadata from the prying eyes of hackers and law enforcement,...
and to do so, the standards body proposes encrypting DNS connections over TLS.
In August of last year, the Internet Engineering Task Force (IETF) identified ways to improve DNS privacy; the new standards track protocol specification (RFC 7858) spells out how to use TLS encryption to eliminate "opportunities for eavesdropping and on-path tampering with DNS queries in the network."
"DNS Security Extensions (DNSSEC) provide response integrity by defining mechanisms to cryptographically sign zones, allowing end users to verify replies are correct," the RFC authors wrote. "By intention, DNSSEC does not protect request and response privacy. Traditionally, either privacy was not considered a requirement for DNS traffic or it was assumed that network traffic was sufficiently private; however, these perceptions are evolving due to recent events."
Those recent events are the reports of pervasive monitoring of various forms of communication by government agencies, which the IETF community sees as a form of malicious attack regardless of the intent of the monitoring entity or whether it is being performed legally by law enforcement agencies or illegally by threat actors.
"The motivation for PM [pervasive monitoring] can range from nontargeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation," IETF concluded in 2014. "Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required of the attacker are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols."
Ofer Gayer, senior security researcher with Imperva, said even the small bits of DNS metadata can yield extremely useful intelligence.
"Intelligence gathering doesn't start and end with getting the very deep and darkest secrets of a target. It's a process, an entire world of methodologies, a system," Gayer said. "One of the key components of this system is getting bits and pieces of information -- which are sometimes meaningless alone -- from various sources, inputs and occasions that can then be synchronized, cross-matched and puzzled together to form a bigger picture."
John Heidemann, research professor of computer science at the Information Sciences Institute, University of Southern California, and co-author of the new protocol, said generally there are few risks for DNS metadata, since most Internet users talk to a local resolver.
"But some people choose to use public DNS resolvers (such as those run by Google at 188.8.131.52, and also others run by OpenDNS, Dyn, UltraDNS, Level3, and others). Public resolvers involve sending your DNS queries over the general Internet," Heidemann wrote in an email to SearchSecurity. "Just like webpages sent over the WAN are increasingly encrypted as best practice, we believe that DNS queries should also be encrypted."
Don Jackson, senior threat researcher for Damballa, the security firm based in Atlanta, said the DNS privacy goals of the proposal could mitigate eavesdropping.
"DNS metadata can be used to infer a host's activities, and sometimes [its] affiliations. The current DNS standard does not employ encryption, and hosts will often send plaintext DNS requests for sites they want to visit, even if the connection they make when visiting the site is encrypted," Jackson said. "By eavesdropping on these requests, a third party can approximate what a user might be doing."
Heidemann said he expects that the response by government officials will likely be the same as with other encryption applications.
"Just as governments take different stances on webpage encryption, we expect they will have a similar range of stances on DNS encryption."
Heidemann also admitted that "as with all RFCs, it is up to [the] industry to adopt the specifications. We are hopeful they will do so."
Jackson was not so hopeful about adoption of DNS privacy via TLS.
"I think odds of any significant adoption are extremely low. It's a lot of work -- computational overhead and latency -- for an approach that doesn't completely address the problem," Jackson said. "For example, this addresses only communications between client and recursive resolvers, not authoritative sources."
Jackson added that even improving DNS privacy doesn't address a number of other risks inherent to DNS.
"You have to trust the servers and their operators as well, so it doesn't address evil endpoints. It doesn't hide any actual connection information. To me, it seems a bit like trying to hide the person's name you are looking up in a phone book, but you call the number over the public network, so you have to trust every network operator between you and the one who services that number as well as the person who picks up the call on the other end," Jackson said. "It will keep some sneaks away, but it doesn't afford much protection, especially considering security controls that leverage DNS inspection to the benefit of users."
Find out the risks and rewards of encryption everywhere.
Get a more nuanced take on the encryption debate from RSAC.