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

Brian Dickson <> Mon, 01 April 2019 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E85E1200CE for <>; Mon, 1 Apr 2019 13:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bfHlzYmNBlZv for <>; Mon, 1 Apr 2019 13:33:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 649101201E0 for <>; Mon, 1 Apr 2019 13:32:59 -0700 (PDT)
Received: by with SMTP id k189so6558764qkc.0 for <>; Mon, 01 Apr 2019 13:32:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y0XkbrZFtzEQt46Tp5xIEfXgC1cmff0XF8hSi6IJAEI=; b=GthSqiAmOa9SE0Mo8hJqJGwQEve/HvBq2X9LSmZmQpJVgmgdHks9uuC8lIvGFk71yk Y10POzV9lYnP86/qQbQWoPxmNFABDDOkjGwMXUkoSTqmklpq00Tba0oEqMdP4CWD1GxF Vz9W6Ba7bF4O3md/Rjydazx9Fo+Kw4diQWnQFfYCWwAo+lvJop/KYlc+4xYfDtct9N7k mts9ArpowcSAT+pcud90naaDP9elimue3O/xLHWRXX13GIonZT+i2rSTz8m9CAUHaA3E LYTIO++mdnvjrq5/ARjfKOaiewYcxlEJ7p2KqZ/Qu+OuOk9ozowwJV2/T1WjiiGbNxr2 vmvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y0XkbrZFtzEQt46Tp5xIEfXgC1cmff0XF8hSi6IJAEI=; b=eckeaDEFr9CBp+cfjcY5sddXpmA/rDFmaU6MyxOidShN+vdkQGILKLDHWJ2IpnKm7y LiwxJ+4FVvc8bXE3S4T0uh+lOlI8rMZxAkOZwdBsdl+IORvVMWkJ2thGcp6PPlvB6KtC Sl+UHPmaxykC8oMvx8M2Kacjh7GBimPcY97GPVdsdAV4GEiW/8Y23NYxCilrzzwp5Xls WgHQLfqSti1JDrCxq66WNK4keEjgSlhbVH39R8fhpSMkoFyqYe5Crhs9tIp4O5SwLcYI i0fJMyQZtlUwa2Z32Vg+o6FUG0lsaBX/Liu3QaeSRnom/T0JxNbZDZCOgRxDCDFNfSkZ AYLQ==
X-Gm-Message-State: APjAAAVjSrQ/D0/scTUp7lYdNh6YCNHEPpFqisRBnryHTeei+3JieDxq wct0sldtseDj78Pd5lOFn1P/qAyiWUVZ4DQEbeE=
X-Google-Smtp-Source: APXvYqxsuHN9k8wFYyoVx9e3V1F1BAD1AvJIRjnSXM3huAgekHBKL5H4LPtD2c3ckwzCvvKanXvXGPvw6j4IbpxqEtE=
X-Received: by 2002:a37:784:: with SMTP id 126mr50255697qkh.10.1554150778569; Mon, 01 Apr 2019 13:32:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Mon, 1 Apr 2019 13:32:46 -0700
Message-ID: <>
To: Eric Rescorla <>
Cc: DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000158d4a05857ded90"
Archived-At: <>
Subject: Re: [Doh] Mozilla's plans re: DoH
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Apr 2019 20:33:09 -0000

On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla <> 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].

> [1]

Looking specifically at the problem statement and evidence, I have a
question about this (or any other) investigative work:
Has there been any related/follow-up work, or other similarly scoped work,
to examine the use of DNSSEC in the domains tested, that you're aware of or
can point folks at?

I.e. Were any of the manipulated domains signed DNSSEC domains, where
validation might have prevented the manipulated responses from being
accepted from the resolver?

Clearly there would still be the issue of being able to find/reach a
resolver that does not manipulate results, but at least the manipulation
would be detected/blocked.

(Percentages overall, and percentages in the manipulated results groups,
would both be interesting and informative.)