Paul, This seems like a fine and modular approach that doesn't boil the ocean.
Eliot On 7/5/14, 5:04 AM, Paul Vixie wrote: > 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 > int-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
