On Tuesday, 12 March 2019 20:52:27 UTC Ted Hardie wrote: > Paul, > > Since it is apparent our disagreement is at a more fundamental level, I > will make only two further comments.
ted, your comments were of such a nature that i had to sleep on them more than once before i felt i could re-engage. i apologize for the delay. let's continue. > The first is that you recently chided someone for using the word "rant", > saying that it would "diminish and disrespect" someone's words. In the > note below you use terms like "warfare" to characterize the work of the > authors; that is both inflammatory and disrespectful. The authors worked > on a chartered working group item throughout the IETF process. You > disagree with the security trade-offs made in the chartering and execution > of that work, and discussion of that disagreement will hopefully be > fruitful. But if you want their respect of your opinion, according them > the respect due theirs will go a long way; they did not make these choices > arbitrarily. i did not intend the term "warfare" to be taken colloquially. i meant it in the literal sense. all war is economic -- the fighting will continue until one party cannot afford to continue. not all war is violent. we do not have a word like "trade" as in "trade war" to describe what's happening here, and we need one, so that i can use that term to describe as accurately as possible what i think is happening. DoH's stated goals include "prevent on-path interference in DNS operations." i am an on-path interferer, and "i aim to misbehave"[1]. DoH is, in that sense, targeted at me. i think it was wrong to do so, not morally wrong, but wrong on its own terms, to falsely equate all on-path interferers. parental controls and corporate security are forms of on-path interference in DNS operations which have a valid and moral place in our digital society. DoH could have distinguished between edge network operators who interfere for reasons our users and their apps are either cooperative with or unwelcome entirely. they did not. they lumped us all together. the method of DoH with respect to preventing on-path interference with DNS operations is to make it too expensive, obviously, because it (deliberately) hides recursive DNS transactions in flows which have been, until now, unaffective of DNS operations. i wish the DoH well in their walk with the GFW, but i predict that the CCCP has effectively infinite resources and resolve, and that it is _not possible_ to exceed their expense budget to the point where they say, "ok, that's the end, everybody in china who wants free and open DNS access can get it, we just can't deal with this DoH thing." however, for non-nation-state actors, such as myself, it's going to be really quite costly to prevent intruders and bots and other malware from moving their DNS operations out of our sight and out of our control. our costs will increase. this increase was deliberate. it would be dishonest not to call that economic warfare by the DoH authors. if this comes as a surprise to them, then so much the worse for all of us, i think. > My second comment is to point out that the IETF has been heading this way > for about five years now. The IAB formalized its early support of this > approach in November of 2014 with this text: > > > The IAB urges protocol designers to design for confidential operation by > > default. We strongly encourage developers to include encryption in their > > implementations, and to make them encrypted by default. We similarly > > encourage network and service operators to deploy encryption where it is > > not yet deployed, and we urge firewall policy administrators to permit > > encrypted traffic. > > > > We believe that each of these changes will help restore the trust users > > must > > have in the Internet. We acknowledge that this will take time and > > trouble, > > though we believe recent successes in content delivery networks, > > messaging, > > and Internet application deployments demonstrate the feasibility of this > > migration. We also acknowledge that many network operations activities > > today, from traffic management and intrusion detection to spam prevention > > and policy enforcement, assume access to cleartext payload. For many of > > these activities there are no solutions yet, but the IAB will work with > > those affected to foster development of new approaches for these > > activities > > which allow us to move to an Internet where traffic is confidential by > > default. i remember this text. DoH is not what i expected as "will work with those affected". the problem of surveillance is differentiated between home and corporate networks on the one hand, and public networks on the other. one perfectly valid approach to the goal set out by the IAB above would have been to say, all network operators who care about DNS privacy, should run their own recursive DNS servers, and, those servers should prefer DoT where available when communicating upstream. that answer was not politically acceptable by other interpreters (that is, not me) of the IAB text. rather, the IAB text was taken as license to change the way DNS resolution would be done for all users. that was overreach, and was a consensus i could not join, and has created more losers than winners, and i view it as either naivety about real internet security issues, or as an abuse of power, depending on who knew how much at what time. > By that point, the IETF working groups were already in formation. Moving > the DNS toward encryption has been going on since DPRIVE and has been > accompanied by the rise of transports like QUIC which are encrypted by > default. You have been working around that, rather than developing new > practices. I invite you instead to consider how you can accomplish what > you need to in an Internet where all traffic is confidential. when you talk about "the Internet" which originally meant simply a "network of networks", you could mean something technical, in which case my network is one of those networks (of which there is a network), and we would likely agree that for networks i build and fund, the traffic will be what i accept, not what is imposed on me. both the payloads, and the form of those payloads. no enterprise or home network operator is going to accept the IETF's mandate as to which traffic must be encrypted on our networks, for example. on the other hand you could mean what christian huitema seems to mean, which is an Internet that is viral, and anything that connects to that viral agency has to accept all of the payloads and formats decreed by the community. i do not expect this view to sway the CCCP, as i wrote above. in any case it does not sway me, either as a home network operator or an enterprise network operator. simply put, i will not have these views imposed on me. not in the form of DoH now, and not in the form of spam back in the 1990's. not ever. > Enterprises > are currently doing that via managed software and environments, and that > approach seems to be well in-line with your practices below. Using > resolution systems for this will not accomplish what you need now, nor will > it do so going forward; it is time for a different approach, rather than > seeking to return to cleartext. i am not asking for cleartext per se, though on my own networks, which i build and fund, i ought to be able to ask for that and get it, and if you insist otherwise, it will be as effective as the IETF's one-time insistence that the end to end principle forbade firewalls, and later, the IETF's insistence that the end to end principle forbade NAT. the consensus you're seeing appears to be in a non-representative bubble. using resolution systems for surveillance and control of edge networks is the world the IETF finds itself in. they can decide to provide other approaches, and they would find me a ready participant. they cannot however simply decide that my approach is wrong or outdated, and say that those days are over. until there is another way to achieve what the internet security industry achieves by watching and controlling DNS operations, those operations will continue, and they will be non-optional on many edge networks. the IETF consensus is not, to borrow a term from christian huitema, "king". what i'm asking for, though, is not clear text. rather, i'm refusing to allow outside answers to naming questions, for the same reasons i would refuse to allow outside answers to ARP questions. the internet only exists by cooperation -- of which interoperability is only one example. when the wide area services, the intermediate networks, the edge networks, the apps, and the users all agree on what should happen, then it happens. otherwise, not so. to want any other system is to be willing to forcibly impose communications on others, which is NOT "the Internet way" and cannot become so, because it would rely on cooperation which can be withheld. (as in my case, with DoH.) > The situation that moved this community to that stance was well-laid out in > IETF 88. We must acknowledge that not all devices which are on-path are > controlled by entities known to the user or network operator and not all of > them are acting in the interests of those parties. Protecting against that > threat requires us to change our ways. Please help, rather than working > around the effort. i don't think you realize what you're asking. the bad guys didn't attend IETF 88. we have a world wide digital civilization to run here, and we will continue doing that, even if it means "working around" disruptions like DoH. if someone from the IETF community wants to work on protecting DNS from the bad guys without also giving the bad guys greater powers that the good guys are nowhere near ready to cope with, my e-mail address is p...@redbarn.org. > regards, > > Ted Hardie > (wearing no hats) i am paul vixie, "concerned internet citizen." thank you for your thoughts. i hope that you will also read michael sinatra's response to this same message. he does not nec'ily speak for me, but he does seem to be making sense here. [1] https://www.youtube.com/watch?v=1VR3Av9qfZc _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop