[I added dns-privacy to the cc list, since that seems like a relevant forum for this discussion.]
On Mon, 07 Jul 2014 11:04:56 -0700, Paul Vixie wrote: >Matthäus Wander wrote: > > ... > > I didn't mean to imply that a DTLS solution can be universally deployed. > > >because the dns is a map to the territory known as the internet, and >because most internet packet flows begin with a dns transaction, i'm >dismissing out of hand anything that will almost universally not work >for some class of user, such as those in hotel room wireless networks, >or behind CPE that either can't pass new protocols or would require >above-average skill to configure for such. > > >in my own configuration i'd set EDNS to be the primary protocol, and >add HTTPS as the first fallback to be tried, so that the fallback to >plain DNS on UDP/53 can be as rare as possible. this may even be a >reasonable default. > >but we can't spend any of our time pretending that the internet >architecture isn't a hostage to a billion poorly built CPE devices, no >matter how hopeful we are as to the future, and no matter how many >personal counter-examples we can cite. These comments bring out a very important question that has been lurking, somewhat unstated: What IS the consensus about the completeness of deployment required to declare "success" for DNS channel privacy? Focusing on middleboxes for now (although deployability applies to servers and users, too): Paul "dismisses out of hand anything that is not almost universal, including hotel rooms and behind broken CPE", because (A) there widespread broken CPE devices and (B) we must protect the Internet architecture from and the global DNS namespace. (To paraphrase.) With those assumptions, arrival at DNS-over-HTTPS [* footnote 1] makes some sense, since HTTPS is the least protocol least-molested by CPE to date [* footnote 2]. But I'm not sure those are the best assumptions to start with. We're talking about *adding privacy* to the existing DNS infrastructure. What's important is that privacy is a *new feature*. Thinking about things this way suggests two observations: 1. One can separate requiring privacy from providing a global namespace. Since the Internet has survived without privacy DNS queries until now, surely it won't melt if some queries continue to lack protection from eavesdropping. About the assumptions: if you accept fallback to current DNS, then new privacy methods that don't reach 99% deployment do NOT break global naming---we can reject assertion (B) if we allow fallback. 2. Because privacy is a new feature, (a) users or companies interested in that feature *can advocate* for it, (b) they *have motivation* to fix it because privacy can be a potential differentiator of what is today commodity service, and (c) some have the *ability* to fix it. Some people will care about DNS privacy and some not. But for those that care, users can replace their CPE, or can request their ISP upgrade their CPE, or switch ISPs. While many users may not do this (many will not care), they all can. As proof, consider reaction to bufferbloat, where publicity has raised awareness. Some users have switched hardware, and I hope new CPE is being more reasonably configured. (Or consider DNSsec. Yes, there have been a couple publicized failures, but one can look for domain providers that advertise DNSsec or not today. And end-users can generally use it, or fall back if they don't care.) This approach can generalize to ISPs or governments, too. If, say, there were a mandate that all DNS users in a state must use DNS privacy, then that state's government could identify local ISPs with broken CPE, and either ask them to estimate the cost of hardware upgrade or software reconfiguration, or estimate the lifecycle of natural CPE turnover. About the assumptions: because users (or ISPs) that care often have some control over CPE, we can sometimes reject assertion (A). In fact, given enough time, all the hardware will turn over. I believe the Internet no longer has any active Fuzzball routers. :-) More seriously, telecos seem to be agressively moving people off DSL now, so perhaps 10 years is plausible EOL for 90% of hardware. We can reject assertion (A) for most hardware if we allow enough time to pass. If you accept that some people will continue with current DNS while others have improved privacy, then we can think about a 10 year rollout and accept that some stragglers with old CPE will continue without privacy for DNS. For users who have strong privacy requirements and refuse to fallback to current DNS---replace your CPE for US$50 OR walk down the block to an open wifi that isn't broken. Some users will stick with old stuff until it dies. See (for example) the lingering installs of Windows XP. That's OK---they know what they're not getting, and they make a choice about benefit vs. cost of upgrading. It seems to me that assumption that "must work for 99% of users, right now, in spite of today's broken hardware, OR it's not acceptable" is a false dichotomy. I hope we consider the several possible designs (some of which may not work for 10% of today's users), not discard them out-of-hand. It may be that fast deployment trumps alternative designs in the end, but let's have that discussion and not cut it off. Back to the question: "what completeness of deployment required to declare success for DNS channel privacy?": My assumptions and a suggested answer: I assume software upgrades to the (a) interested clients and (b) servers. (c) I assume the servers are reasonably current hardware. I assume (c) most CPE doesn't interference, and (d) some interfering CPE can be fixed with a software upgrade. I think success would be (e) 80% of users *can* use DNS privacy (possibly with software installation) in 5 years, and (f) 60% of people *do* use DNS privacy in 10 years. Those are just guesses to put a stake in the ground, and (f) is probably optimistic. But to me "immediate and near universal" is not a requirement for success. Which perhaps raises the question: how often will CPE actually interfere with whatever we try? I don't know, but the closest data I know of is from Netalyzr in 2011 (see "Implications of Netalyzr's DNS Measurements" by Weaver et al, SATIN). They say: 88% of their sessions are behind NATs, and 73% of these hit a DNS proxy---so there's a lot of CPE in the way by default. BUT they estimate that about 1.4% of sessions are "proxied or modified by the network" when they try to directly talk past the CPE, so it may be that most CPE will get out of the way if one choses to bypass it. So sure, we can use DNS-over-HTTPS to bypass the CPE. But this data suggests we could also use DNS-over-TLS or -DTLS to do the same. I'll cut off this long note here, just focusing on deployment CPE. But similar questions come up around deployment in the client itself and in the servers (recursive and authoritative). It's been suggested that solutions must work on old server hardware. That too seems like an overly strong constraint to me. (And, by they way, a constraint that is completely incompatible with standing up a bunch of new webservers to run DNS-over-HTTPS.) That's a related but hopefully separable discussion. [* footnote 1: DNS-over-HTTPS: the Bortzmeyer JSON encoding was mentioned, and XML has been proposed and I-D'ed before.] [* footnote 2: I'm not sure I believe the assumption is that HTTPS is nppever interferened with. Some companies put up TLS-intercepting middleboxes to snoop TLS to "protect their employees", so even HTTPS is no longer free from interference and assumptions.] -John _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
