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

Eric Rescorla <> Mon, 01 April 2019 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AF531201EB for <>; Mon, 1 Apr 2019 13:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hu32U4OTXS1C for <>; Mon, 1 Apr 2019 13:46:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B75F1201E0 for <>; Mon, 1 Apr 2019 13:46:17 -0700 (PDT)
Received: by with SMTP id v14so7323825lfi.0 for <>; Mon, 01 Apr 2019 13:46:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QBRWZXXm7UdoCzL0SzUm6BIaDWTGT2R3UhyC/Kc4UEw=; b=E+tkGZhDfSBXYY7pmZCO4u9u7QrM5rnDyIPVvSD7pMkI1kU7UwW7xSxaTPRk7Z83hm 0qpryTfhBddNCljnmvOjUX0zkhkRvj7tzsydOGF1RHAM+J0UISCrsRRlrodTuFTg640T rshJp2lnZnUMjIaqudvb63LJ+Xbbystokri9E3vWOcOTy8aXx1k2W5jJYdErOkCpy9bP erKeC8aW5oJpJC8AwsMBEZuLeKAdw5t6F3+L7nB0HP8y2QHPbM2oP62q/2jAQvjnbTsw OgcphPvUxze0tPVkmQzVMfT89E1Ygw90NJlzft/FRzfEWrxrYVl+52jHcc4kFkB/Rf8V +iZA==
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=QBRWZXXm7UdoCzL0SzUm6BIaDWTGT2R3UhyC/Kc4UEw=; b=ZGigtmoC/xybsOjQj/5KUNpsUA8NRAifXPavE2xywZOdFSpf8OHE6BijAQ4gkuIeCj Ygt3MR5BC7bhmaf1pwfbcOHVJ5ep64ByOoIwPOP73kwraeGqxOsroXpxrQyAsOH2XP/D tnH05srfqjz0654DEEn32OIwWH79cIKTlnr2JLojdWBNGwzFgO8L5qGhDLIjk370S0Sk CvW/oEjwIMRRNm6Sis9yXXB9KG2ZgCjMe9Nfa753XoZuzHEuZJHnor+g9HUqgWU8zvxH 1nVW4p5A+8K2Kb6/vpn1zmDXYH1Y71VR/WztVui+3cZyez3zbYELmezlla+DK+aZMN55 1AkQ==
X-Gm-Message-State: APjAAAViWZMqcX4bmkMEdDAkUocxXrGM9jNwM9TdDzLtfPcpgrSCWW8c wJIt/2f4X0EckYMxioY4ztv0JPPWXvkOKgyjGJ/eAQ==
X-Google-Smtp-Source: APXvYqzHCBR6ADNdMy4kCvC9cYdXBElBrfK22xh17wgy7bs18G4P5UQgvvE9fq4/OG412cKoBn+Ym3YFhBrZQ7Bn6aQ=
X-Received: by 2002:ac2:52a6:: with SMTP id r6mr35429333lfm.27.1554151575259; Mon, 01 Apr 2019 13:46:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 1 Apr 2019 13:45:38 -0700
Message-ID: <>
To: Brian Dickson <>
Cc: DoH WG <>
Content-Type: multipart/alternative; boundary="00000000000092264a05857e1cf0"
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:46:20 -0000

On Mon, Apr 1, 2019 at 1:32 PM Brian Dickson <>

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

I don't have much more information than is in the paper (you'll note I'm
not an author), but generally DNSSEC doesn't help that much here. You can't
safely do DNSSEC validation on user-facing clients because of a combination
of tampering by middleboxes (typically record stripping, etc,. not really
"attacks") and errors in the published DNSSEC records.

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