[Doh] Mozilla's plans re: DoH

[Eric Rescorla <[e-mail]>]

I’ve heard a number of questions about Mozilla’s plans around
DoH. We’ve made a number of public statements, but it might be useful
to try to put this all in one place.

In context, the problem we are attempting to solve here is attack on
the user’s name resolution from an attacker with full or partial
control of the network, as contemplated by Section 3 of BCP 72 as well
as BCP 188. There’s ample evidence of monitoring/manipulation of user
traffic via this vector [0][1][2]. Importantly, this includes cases
where the entity which owns the network infrastructure monitors and/or
modifies DNS requests and responses without the user’s consent.


With that problem statement, here are our plans:

    1. We have implemented DNS over HTTPS [RFC8484] and would like to
    deploy it by default for our users. We intend to select a set of
    Trusted Recursive Resolvers (TRRs) that we will use for DoH
    resolution. TRRs will be required to conform to a specific set of
    policies intended to protect user privacy. We’re still refining the
    final policy but we expect it to roughly match the one that Cloudflare
    has already agreed to use
    (https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/).While
    we expect the initial set of TRRs to be small, we’re interested in
    adding new providers who are able to comply with these policies.

    2. The precise details of the user interface are TBD, but we expect
    something like the following:

    3. Copies of Firefox will be configured with a set of TRRs. Different
    regions may have different TRR sets or different defaults. In addition
    we may have DoH/TRR on by default in some regions and not others,
    especially initially.

    4. The user will be informed that we have enabled use of a TRR and
    have the opportunity to turn it off at that time, but will not be
    required to opt-in to get DoH with a TRR.

    5. Any given client will automatically select a resolver out of that
    set and use that for all resolutions [with the two exceptions noted
    below.]  At any time, the user will have the option to select a
    different resolver out of the list, specify their own resolver, or
    disable DoH entirely.

We have heard a number of concerns about the ability of the network to
control the client’s resolver behavior. As noted above, just allowing
the network to dictate the DoH resolver would obviate the security
objective listed above. However, there are two more restricted cases
in which we do think some network control of the resolver is
reasonable.

In cases where the network has a preferred resolver that is on our
approved list we might want a mechanism like
draft-ietf-doh-resolver-associated-doh to guide resolver
selection. We’re watching that document’s progression carefully.

    1. In cases where the network also controls the client (e.g., they are
    able to remotely manage it via MDM), then they should be able to
    select the resolver themselves, disable DoH, etc.

    2. We realize that in the short run, the need for resolvers to be on
    our list creates some challenges for resolver operators.  We would be
    open to discussing how to adapt our security constraints to suit the
    needs of multiple applications, so that as more systems deploy
    DoH/TRR, they can share a list of resolvers vetted to a common
    standard.

There are still a few open issues that we have to sort out, but if
some of the above isn’t clear, I’m happy to try to explain. One thing
I am not able to provide is a detailed timeline. We are still
performing measurements [3] to determine whether users will experience
problems with DoH/TRR enabled, as well as figuring out precisely how
we intend to deal with split horizon DNS, and will need to address
these issues prior to shipping.

-Ekr

[0]
https://cdt.org/blog/dns-strengthening-the-weakest-link-in-internet-privacy/
[1]
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pearce.pdf
[2] Many networks redirect NXDOMAIN to a search/advertising page.
[3] For some of our previous experiments, see:
https://blog.mozilla.org/futurereleases/2018/09/13/dns-over-https-doh-testing-on-beta/
https://blog.nightly.mozilla.org/2018/08/28/firefox-nightly-secure-dns-experimental-results/