Paul, > (yes, i will be part of a major new project to identify and block all DoH services, so > that behavioural security policies can still work, because you may have > noticed that the internet has never become MORE secure from new tech, > but it occasionally becomes LESS secure more slowly because of policy.)
I would be very interested, if you are so inclined, to hear more of what you are thinking. Is this something you can (are willing to) talk about? It sounds like a very thought-provoking initiative. Thanks, Nalini On Mon, Mar 11, 2019 at 10:55 AM Paul Vixie <p...@redbarn.org> wrote: > > > Christian Huitema wrote on 2019-03-10 21:14: > ... > > There are a bunch of conflicting requirements here, and it would be good > > to tease out the contradictions. Consider the following cases: > > > > 1) I am using my phone, and using application-X. > > > > 2) I am at home, using application-X on my home computer. > > > > 3) I am using Wi-Fi in a hotel, and using application-X. > > > > 4) I am using my work laptop on the enterprise network, and using > > application-X > > > > 5) I am using my work laptop in a hotel, and using application-X > > > > 6) I am using my work laptop on the network of a customer, and using > > application-X. > > this distinction is not useful. > > there are two cases. > > a user or app trusts its network. > > or not. > > in the first case, you'll use an RDNS service which is in the set > (allowed (preferred)). that is, you'll use the server you desire most > out of the set that your network operator allows you to reach. > > in the second case, you'll use a VPN, for all of your traffic, not just > for DNS, because if you hide your DNS but not the connections which > result from such hiding, it will add no measurable privacy. > > > Today, plenty of people claim the right to control how I use the DNS: my > > phone carrier, my ISP at home, the company that got the contract to > > manage the hotel's Wi-Fi, the IT manager for my company's laptop, the IT > > manager for the company that I am visiting. Out of those, there is just > > one scenario for which the claim has some legitimacy: if the company > > pays for my laptop and own the laptop, yes of course it has a legitimate > > claim to control how I am using it. Otherwise, I, the user, get to > > decide. If I like the application's setting better than the network's > > default, then of course I expect those settings to stick. > > this distinction is also false. > > if you are using my network, then it makes no difference which of us > bought you that laptop. you will use the RDNS i allow you to use. RDNS > is part of the control plane, and i use it for both monitoring and > control. sometimes that's so that i can see malware beacon to its C&C. > sometimes that's so that i can institute parental controls. > > if you don't like my rules, you should vote with your feet, and not > visit me. because that is the only choice you will have. (yes, i will be > part of a major new project to identify and block all DoH services, so > that behavioural security policies can still work, because you may have > noticed that the internet has never become MORE secure from new tech, > but it occasionally becomes LESS secure more slowly because of policy.) > > quoting again the salient passage of RFC 8484's self-damning introduction: > > > ... Two primary use cases were considered during this protocol's > > development. These use cases are preventing on-path devices from > > interfering with DNS operations, ... > > let me give you advance notice: "i aim to misbehave."[1] that is, _i am > on-path, and i intend to interfere._ why on earth the IETF decided to > equate dissidents (of whom there are tens of thousands, all of which > need full VPN's not just DoH for actual safety) with bots (of which > there are tens of millions), and set up a war between end users and > network operators, i will never understand, or try to. now, we fight. > > -- > P Vixie > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
