[Doh] Mozilla's plans re: DoH

Eric Rescorla <ekr@rtfm.com> Wed, 27 March 2019 09:16 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9298B12042B for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 02:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id X4TDB8gd8MrD for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 02:16:45 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C40F120575 for <doh@ietf.org>; Wed, 27 Mar 2019 02:16:45 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id r24so12632660ljg.3 for <doh@ietf.org>; Wed, 27 Mar 2019 02:16:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bRkxNxasmELdmJuEH4R4/KkOJBcm+WZ2UmlE+wi1zrc=; b=st5RxO+i02r1NC6PuVCE/2QOU966o2MoJyUTMfdHPnd91R+XzZMfQkOkMs741PCK4U 6mh9eO4aLLlNRNleD42b4rxfJ2Ta0a/47ayOtovnD771vZ5xQAsameI2ANi7qywPbjk5 ohSQ/iExmB99u4IisKhJ3IuuqklV1re21EjTbghLZ6JEF//R9CPcbJBxPC5VZBuFCyZW RwPiTTgCPWb9TMvWUfcbMpGM3risPzEAL6FzqvevaRxLCwn0VDwP8c+Mfa/EF06H142q BgT9irEIT0fTJPigMtvJz7quii17QYQHYy34fCuBsfAY9Iw7pfzhOEb2uQ0kxYhdCP2N jefg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bRkxNxasmELdmJuEH4R4/KkOJBcm+WZ2UmlE+wi1zrc=; b=saaF3BBzfcV754krmfGtrMItKXExFjhAaFmDdp+sYp2+U6OhacOWX+knd2xk5FvL+k VfdT38m6J99NHu+PJ1xpajyhC03d1AaR40+AibM+8prFfz0gHrg2A9VHQfZ00ySo1+uh B/H/VHjL+L3l2VkrgDLsRTl46j/e6WgRbrFlgLt1lDB3SjNCezdg+H3DVeQckbUJP1Bn g5fRIiYyxaY3AEINeSg2pP9bMRzz0QHSqY75xOnBdEDd0nnR6n0h8sOR8hk8Tl9JRA56 5Fd1aOEEttgdIIsJqb/wG41uVeG1EI2jsGnZyx5QgAk1pz/ov8Jt5Au0jsscUv8e/CEa ccUA==
X-Gm-Message-State: APjAAAXKYTcav8QzKonX/7cYxrLt0gyFmylQHdBVK3c74iTKrYHmIDUA JTKFJ7m4PIUgwt2scO/HdlZ82sbWedO1lYjcHUMasGmIIa4=
X-Google-Smtp-Source: APXvYqzUMBPhG/ca79C96obwdGerWks4E4tQ1T5eKprm+dEyvf1BWhQE4zk7avcX3Re5A7R0OimZ7/seobouuAVhVJk=
X-Received: by 2002:a2e:8905:: with SMTP id d5mr4771432lji.59.1553678202837; Wed, 27 Mar 2019 02:16:42 -0700 (PDT)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 27 Mar 2019 02:16:05 -0700
Message-ID: <CABcZeBOk5bM+3G2Jd3Lu33Z08gc=AeoZ8UFHzN6AYk4f_hjZ8Q@mail.gmail.com>
To: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000060308105850fe56d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw>
Subject: [Doh] Mozilla's plans re: DoH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 09:16:58 -0000

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

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

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.


[2] Many networks redirect NXDOMAIN to a search/advertising page.
[3] For some of our previous experiments, see: