Re: [Doh] Mozilla's plans re: DoH

[Eric Rescorla <[e-mail]>]

Now with the numbered lists correctly formatted:

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:

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.
The precise details of the user interface are TBD, but we expect
something like the following:

    1. 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.

    2. 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.

    3. Any given client will automatically select a resolver out of that
    set and use that for all resolutions [with the two exceptions noted
    below.]

    4. 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/








On Wed, Mar 27, 2019 at 2:16 AM Eric Rescorla <[e-mail]> wrote:

> 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/
>
>
>
>
>
>