i've now seen a number of proposals reaction to "the snowden disclosures", seeking channel encryption for dns transactions. i have some thoughts on the matter which are not in response to any specific proposal, but rather, to the problem statement and the context of any solution.
first, dns data itself is public -- the data is there for anybody to query for it, if you know what to query for. only the question, questioner, and time can be kept secret. answers are only worth keeping secret because they identify the question, questioner, and time. second, dns transactions are not secret to protocol agents. whether stub resolver, full resolver, forwarder, proxy, or authority server -- the full identity of the question must be knowable to the agent in order to properly process that question. if the agent does logging, then the question, questioner, and time will be stored and potentially shared or analyzed. by implication, then, the remainder of possible problem statement material is "hide question from on-wire surveillance", there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with "hide question from on-wire surveillance by third parties." this is extremely narrow but i can envision activists and dissidents who rightly fear for their safety based on this narrowly defined threat, so i'm ready to agree that there should be some method in DNS of providing this secrecy. and as we know from the history of secrecy, if you only encrypt the things you care about, then they stand out. therefore, secrecy of this kind must become ubiquitous. datagram level channel secrecy (for example, DTLS or IPSEC) offers a solution which matches the existing datagram level UDP transport used primarily by DNS. however, the all-pervasive middleboxes (small plastic CPE devices installed by the hundreds of millions by DSL and Cable and other providers) have been shown to be more powerful than IPv6, DNSSEC, and EDNS -- we could expect them to prevent any new datagram level channel secrecy protocol we might otherwise wish to employ. TCP/53 is less prone to middlebox data inspection, and may seem to be an attractive solution here. i think "not" for two reasons. first, TCP/53 is often blocked outright, and second, because TCP/53 as defined in RFC 1035 has a connection management scheme that prohibits persistent TCP/53 connections at Internet scale, and we cannot afford the setup/teardown costs of a non-persistent TCP-based channel secrecy protocol for DNS. to those who suggest redefining TCP/53 and upgrading the entire physical plant and all software and operating systems, i challenge you to first show how this is less global effort than other proposals now on the table, and then show how you would handle the long-tail problem, since many agents will never be upgraded, or will only be upgraded on a scale of half-decades. DNS works today because TCP/53 is a fallback for UDP/53. its definition and deployment makes it unsuitable either currently or as-would-be upgraded to become the primary transport. i suggest that any channel secrecy protocol we wish to add to the DNS system must be suitable as the primary transport, to which the existing UDP/53 and TCP/53 protocols are fallbacks. i further suggest that any new transport be operable at internet scale, which demands connection persistence. finally i suggest that this be done using a protocol that the internet's "middle boxes" (cheap CPE devices who think they know what all valid traffic must look like) will allow to pass without comment. one candidate for this would be RESTful JSON carried over HTTPS. because of its extensive use in e-commerce and "web API" applications, HTTPS works everywhere. because HTTPS currently depends on X.509 keys, other groups in the IETF world are already working to make HTTPS proof against on-path surveillance. (google for "perfect forward secrecy" to learn more), and others are working to defend the internet user population against wildcard or targeted SSL certificates issued by governments and other anti-secrecy agents with on-path capabilities. stephane bortzmeyer has already shown us that JSON representation of DNS transactions is possible. i have heard from another protocol engineer who is also working in this area (and who credits bortzmeyer for informing his work). the special advantage of TCP/443 as a primary transport for persistent DNS with channel secrecy is that HTTPS's connection management permits massive scale, as in, a single protocol agent with tens or hundreds of thousands of open connections, even with local and global load balancing and connection pinning. in summary, i agree that we have a narrowly defined problem of on-path surveillance of dns questions by third parties, but i do not think it can be solved by further EDNS extensions to UDP/53, and i know it cannot be handled by using or redefining TCP/53. i have identified a way forward that relies on TCP/443, noting that other groups are already repairing SSL to add perfect forward secrecy and to solve the "government-controlled X.509 CA" problems, and that we can leverage that work. i've suggested that we specifically focus on the bortzmeyer solution involving RESTful queries and JSON responses, or perhaps RESTful URI's using POST of JSON, and JSON responses. thank you for your time spent reading this. note that i am not a member of int-area@ but am allowed to post there, so, if you want me to see your response, please cc me. vixie _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
