Intent to experiment and launch: DNS over HTTPS auto-upgrade in Chrome (Targeting M78: branch cut @ Sept 5th; estimated Stable @ Oct 22nd)

[Kenji Baheux]

Bcc: chromium-dev@

Hi all,

This is a heads up about our short term plans for DNS over HTTPS in Chrome (design doc).

DNS over HTTPS is, as the name implies, a protocol to perform Domain Name System resolution over HTTPS, i.e. converting a site name into an IP address over an encrypted channel.

Motivation

Most DNS resolution today occurs over an unencrypted channel. This is bad for privacy and for security reasons. Anyone who is on-path can eavesdrop on your browsing habits or even tamper with the resolution to have you navigate to a phishing website or an “access blocked” page for censored sites (see https://tools.ietf.org/html/rfc7626#section-3 for examples).

This is a complex space and our short term plans won’t necessarily solve or mitigate all these issues but are nevertheless steps in the right direction.

Tentative plan

For the first milestone, we are considering an auto-upgrade approach. At a high level, here is how this would work:

• Chrome will have a small (i.e. non-exhaustive) table to map non-DoH DNS servers to their equivalent DoH DNS servers. Note: this table is not finalized yet.

• Per this table, if the system’s recursive resolver is known to support DoH, Chrome will upgrade to the DoH version of that resolver.  On some platforms, this may mean that where Chrome previously used the OS DNS resolution APIs, it now uses its own DNS implementation in order to implement DoH.

• A group policy will be available so that Administrators can disable the feature as needed.

• Ability to opt-out of the experiment via chrome://flags.

In other words, this would upgrade the protocol used for DNS resolution while keeping the user’s DNS provider unchanged. It’s also important to note that DNS over HTTPS does not preclude its operator from offering features such as family-safe filtering.

Tentative timeline

We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.

Best regards,

[Yoav Weiss]

Upgrading from regular DNS servers to DoH seems like a great path forward, at least for initial experimentation!

I don't know if you intended for this to go through the intent process (pun not intended...). But, as far as I can tell, this is not web exposed (developers will not be aware of the underlying protocol that was used for DNS queries), so from my perspective no LGTMs are required here.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CADWWn7U%3DnjSD9vJm5Ggpw4gGGdAGOJV5UZvxSpJEN%3DEJxWe8LA%40mail.gmail.com.

[Kenji Baheux]

On Thu, Jul 18, 2019 at 4:11 PM Yoav Weiss <yo...@yoav.ws> wrote:

Upgrading from regular DNS servers to DoH seems like a great path forward, at least for initial experimentation!

Thank you!

 

I don't know if you intended for this to go through the intent process (pun not intended...). But, as far as I can tell, this is not web exposed (developers will not be aware of the underlying protocol that was used for DNS queries), so from my perspective no LGTMs are required here.

Correct. This is more of a PSA but we are using this opportunity to hear feedback in case we missed something really important so that we can adjust our plan accordingly.

[winfrie...@googlemail.com]

Sounds good! But managing this "table" could get a complex process. Why not simply ask the standard resolver for a special (TXT) record, which can contain the DoH URI?

[Ryan Sleevi]

While this change should be largely transparent, and thus arguably in PSA territory, there are web-visible side-effects worth calling out.

For example, some carriers/ISPs (or even resolving libraries) may modify the DNS request to include an EDNS Client Subnet indicator, which can then alter the responses received from the authoritative responder. The transition to a secure mode of DNS will prevent that tampering by intermediates, by design, so this may result in different DNS results if servers were relying on or assuming that on-the-wire adversaries should be able to modify DNS traffic at will. Alternatively, the transition from a system resolver library that may be configured to include an EDNS Client Subnet to a library that does not/is not configured in the same way can similarly expose this.

Developers can see this observably through Network Error Logging's server_ip functionality, which may now return different results; although, unless being tampered with, they should be results that the server itself has configured (some of) its DNS responders to respond to. They may also see these metrics in TTFB & friends, if a suboptimal route is picked on the basis of the absence of the Client Subnet.

This is similar to past discussions around Secure Contexts. Namely, if a Website is assuming that an ISP will modify requests or responses (e.g. for zero-rating or ad-injection or attribution), and it no longer does, then from the PoV of the Website, an observable behaviour has changed. The substance, however, is that such behaviour was not guaranteed by the platform, and was resting on a security vulnerability, and thus is not a change to the invariants the platform guarantees, just how they incidentally worked. Whether or not that is web exposed depends on how much you lend towards Hyrum's Law [1]

[1] http://www.hyrumslaw.com/

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACj%3DBEixWaRket29oBLhhVPGJEfSNh2OkXEC1OhcbT%2BPngRpEQ%40mail.gmail.com.

[kenji...@google.com]

On Friday, July 19, 2019 at 1:27:04 AM UTC+9, winfrie...@googlemail.com wrote:
> Sounds good! But managing this "table" could get a complex process. Why not simply ask the standard resolver for a special (TXT) record, which can contain the DoH URI?

The problem with such an approach is that it's happening over an insecure channel (plain DNS) so the client can't really trust the response. Even if the insecure channel concern went away, a client has no way to know on its own if a given resolver is trustworthy. Hence, the need to inject a notion of trust, e.g. a list in the simplest form, which is really the expression of a belief (client's owners).

In short, I think it's an approach that ends up into the opportunistic security/privacy realm (https://tools.ietf.org/html/rfc7435). So, there could be some value but we won't be able to know for sure, making any sort of UX signalling impossible. And, I guess that we will have similar uncertainty with users who are running their own DNS resolver.

[winfrie...@googlemail.com]

Understood, thank you! But in case the table contains the Doh URIs, dhe problem of resolving the "bootstrap" domain over a plaintext protocol persists. Another concern is that at least here in Germany it is common that your home gateway ist the "system’s recursive resolver". And that is a private IP addres such as 192.168.0.1. That means, the Chrome browser is not able to identify the "real" ISPs resolver.

[Katharine Daly]

We've broadened the sharing permissions for the design doc so that folks without chromium accounts now have view access.  (Note that the link has changed as a result; the doc shared in the first post no longer contains any content.)

[Christian Biesinger]

That seems like a very inefficient way to do DNS resolving. Why not do
DNS-over-TLS, since DNS already supports a TCP transport?

Christian

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CADWWn7U%3DnjSD9vJm5Ggpw4gGGdAGOJV5UZvxSpJEN%3DEJxWe8LA%40mail.gmail.com.