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

Neil Cook <neil.cook@noware.co.uk> Wed, 27 March 2019 16:15 UTC

Return-Path: <neil.cook@noware.co.uk>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8D71202F9 for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 09:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkDl44lFoxoM for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 09:15:17 -0700 (PDT)
Received: from mail.noware.co.uk (unknown [IPv6:2604:a880:0:1010::add:2001]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA261202E4 for <doh@ietf.org>; Wed, 27 Mar 2019 09:15:17 -0700 (PDT)
Received: from [10.101.2.154] (unknown [176.12.107.132]) by mail.noware.co.uk (Postfix) with ESMTPSA id CE9B21D8251 for <doh@ietf.org>; Wed, 27 Mar 2019 16:11:33 +0000 (UTC)
From: Neil Cook <neil.cook@noware.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 27 Mar 2019 16:15:14 +0000
References: <CABcZeBOk5bM+3G2Jd3Lu33Z08gc=AeoZ8UFHzN6AYk4f_hjZ8Q@mail.gmail.com> <CABcZeBPUh6x=D+GfKg11+4bRouZdm1LcZvLm1jd4UUEJA832BQ@mail.gmail.com>
To: DoH WG <doh@ietf.org>
In-Reply-To: <CABcZeBPUh6x=D+GfKg11+4bRouZdm1LcZvLm1jd4UUEJA832BQ@mail.gmail.com>
Message-Id: <CEADD7D7-49B5-436F-A1E2-DF5C9AA57FA9@noware.co.uk>
X-Mailer: Apple Mail (2.3445.101.1)
X-VADE-SPAMSTATE: clean
X-VADE-SPAMSCORE: 0
X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrkedvgdekudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfpgffknfevqffqmfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfuffhfvfgjkffosehtqhhmtdhhtdejnecuhfhrohhmpefpvghilhcuvehoohhkuceonhgvihhlrdgtohhokhesnhhofigrrhgvrdgtohdruhhkqeenucfkphepudejiedruddvrddutdejrddufedvnecurfgrrhgrmhepihhnvghtpedujeeirdduvddruddtjedrudefvddphhgvlhhopegluddtrddutddurddvrdduheegngdpmhgrihhlfhhrohhmpefpvghilhcuvehoohhkuceonhgvihhlrdgtohhokhesnhhofigrrhgvrdgtohdruhhkqedprhgtphhtthhopeguohhhsehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/S7rNGZ4erA1bQZk-dwKcMdNo5CY>
Subject: Re: [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 16:15:19 -0000


> On 27 Mar 2019, at 09:24, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 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.
> 

But Mozilla doesn’t know whether the modification is with or without the user’s consent. As the various drafts that have been presented this week attempt to make clear, there are a large number of use cases where users actively want the modification of their DNS (parental control, enterprise networks, malware/phishing detection, botnet C&C communication disruption etc.), indeed they may even be paying for such a service.

So the Mozilla answer to possible DNS modification without user’s consent is to enable over-the-top DNS resolution for all users, using an opt-out model (how a normal user is supposed to understand what they’ve been opted into brings up all kinds of user consent issues itself), and sending all DNS requests to a third-party with whom the user almost certainly has no relationship, contractual or otherwise, and potentially located in a third-party country.

To summarise, in an attempt to deal with a possible (but essentially unknown) issue of user consent, Mozilla "would like to deploy it by default for our users.” 

All the above seems rich with irony and contradiction.

Neil