On Sat, Aug 18, 2018 at 05:22:53PM -0400, Ted Lemon wrote: > 1. Why is DoH being used? > 2. What is the thread model that DoH is addressing?
That not yet enough of the internet has been centralized on big cloud providers in foreign jurisdictions, I think. (this post does get DNS operational after a few paragraphs) It borders on the ridiculous that we have CDNs and browser vendors pushing this service for free, at great cost, claiming they are doing it out of the goodness of their hearts. I can imagine the board meeting already in the SOMA district in SF. Big powerpoint presentation. "We're going to allocate resources to enhance the privacy of people who aren't even our customers". Investor representatives look up and ask "why??", well goes the response, because we lie awake at night that some providers are attempting to monetize DNS, and we can't let this horrible invasion of privacy continue unabated! Meanwhile said users are browsing webpages laden with trackers by dozens of companies already monetizing that traffic. Furthermore, the DNS of >600 million people is already hosted by service providers not allowed to monetize DNS. So for a ton of people, we're moving DNS from highly regulated telecommunications companies to a VC-backed CDN that cooperates closely with heavily censoring regimes in order to get business. Additionally, the operational community is up in arms since this move will break their intranet, their local security policies, their VPN domain overrides and their threat monitoring. The CDN providers have also made it clear they will colocate the DoH service on IP addresses that carry "unblockable" content, forcing system administrators into a Solomon judgment: shall we take down the CDN that carries 'jquery' and break half the internet, or shall we allow uninspectable DNS? In this way, popular content serves as a human shield to protect DoH against blocking. Malware authors will surely love this dilemma too and be sure to move all their DNS lookups to the colocated service - where we can never spot them. But apparently the interest in enhancing users privacy by moving DNS to a third party, by default, is so large that all these worries do not matter. I find this very hard to believe. (Mind you - Mozilla is on record that they want to turn this on by default. There has been some weaselwording around this on Twitter by people claiming not to speak for Mozilla, but no denial. So for now, we can safely assume they are seriously intending to turn on DoH by default - https://blog.ungleich.ch/en-us/cms/blog/2018/08/04/mozillas-new-dns-resolution-is-dangerous/ ) I've been trying to understand what everyone is up to, but I find myself in a 'Sherlock Holmes' situation where all reasonable explanations don't work. Why is there this massive push to enable DoH by default? The CDN providers in question must adhere to strict privacy policies and allow themselves to be audited. So there's no immediate monetization possible. However, looking up all domain names with CDN provider A does mean users would then, by default, have to access all sites hosted at CDN provider B through provider A. This is an area where "rent seeking" https://en.wikipedia.org/wiki/Rent-seeking is entirely possible. And lo, we are already seeing it! CDN Provider B relies on EDNS Client Subnet for some of the largest service providers in the world and CDN provider A is not going to supply those 24 bits of address to CDN provider B! Immediately, rolling out DoH by default is going to hurt CDN provider B. I realise I'm screaming into the void a bit, but whenever someone says "centralise this stuff on me, it will be better, and I'm spending big on it for the love of your privacy", I am worried. Especially when such a move will incidentally kill intranets, VPNs, split horizon, DNS monitoring & DNS malware detecion and blocking. So to round this off - I am not clear what threat DoH-in-the-browser-to-a-third-party is protecting us against. Bert > 3 How does adding this configuration mechanism impact DoH's ability to > address that threat model? > > On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša < > mvavrusa=40cloudflare....@dmarc.ietf.org> wrote: > > > Hi, > > > > this is a bit off topic, but I figured it would be useful to solicit > > some early feedback. The current status is that for secure (as in > > RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism, > > and it's also out of scope for [0]. At the same time we're seeing real > > world deployment of clients which either: > > > > a) Probe port 853 and use DoT in opportunistic profile, or probe 443 > > and trust WebPKI > > b) Statically configure ADN and/or SPKI pins with well known public > > resolvers > > > > This approach works if there's someone maintaining the statically > > configured information, as with the dnscrypt-proxy stamp lists [1]. > > However in most networks the default resolver configuration is pushed > > through DHCP, so it's the network operator that's in charge for > > providing default DNS resolver configuration (unless the user is a DNS > > aficionado and overrides it), but there's currently no good way to > > provide information required to identify and securely bootstrap a > > connection to a resolver using DoT or DoH. > > > > This draft adds an option to provide a capability list for each > > configured resolver. The three defined capabilities are TLS with SPKI > > pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this > > information and stores it similarly to resolver list and domain search > > path for applications to read. Another possible solution for this is > > to use the system of stamps from dnscrypt-proxy, but it's probably > > less legible for clients and duplicates information that's already in > > the recursive DNS nameservers DHCPv4/v6 option. > > > > The draft does not change the trust model, an end-user or an > > application can still disregard DNS recursive nameserver list from > > DHCP, for better or worse. > > > > Here's the draft: > > https://github.com/vavrusa/draft-dhcp-dprive/blob/master/ > > draft-dhcp-dprive.txt > > > > Marek > > > > [0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1 > > [1]: https://download.dnscrypt.info/dnscrypt-resolvers/v2/ > > public-resolvers.md > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
