Re: [Add] [EXTERNAL] Re: Malware adopting DoH

"Robert Mortimer" <robm@scramworks.net> Sun, 15 September 2019 10:30 UTC

Return-Path: <robm@scramworks.net>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A411200A1 for <add@ietfa.amsl.com>; Sun, 15 Sep 2019 03:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scramworks.net
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 mE-ed1N3BiBr for <add@ietfa.amsl.com>; Sun, 15 Sep 2019 03:30:40 -0700 (PDT)
Received: from knid.scramworks.net (knid.scramworks.net [IPv6:2a01:4f8:c17:50eb::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3210212000F for <add@ietf.org>; Sun, 15 Sep 2019 03:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=scramworks.net; s=bofh; h=References:In-Reply-To:To:From:Subject:Message-ID :Date:MIME-Version:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GH8rjb9PX/fA8sHYyLc85D8gYiuAfhILwPDCIPcDR2c=; b=bPh/ovPfECGxJ7LJ5N2dw6b3Ug bVD157xpDo5i9GfO4G1WOoBeQDD6PBJZ2CJGINTh5JTl74T+CFCVYbVbWSDkw/DwqeGuoaohfvgi4 2AIJf8D7ui62OkLp42hylgZxhcDQXbIm2Zy8lG4ciP0YwOQbofo7Cep7+JC+0Z5Wn6AE=;
Received: from [90.255.29.36] (helo=[192.168.1.6]) by knid.scramworks.net with esmtpsa (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from <robm@scramworks.net>) id 1i9Rne-0003zb-Bn; Sun, 15 Sep 2019 11:30:35 +0100
Content-Type: multipart/alternative; boundary="----=_NextPart_59257122.179571700182"
MIME-Version: 1.0
Date: Sun, 15 Sep 2019 11:29:34 +0100
Message-ID: <ae179431-f215-4138-b103-d6cc173a8952@getmailbird.com>
From: Robert Mortimer <robm@scramworks.net>
To: Ted Lemon <mellon@fugue.com>, add@ietf.org
In-Reply-To: <2970473C-046A-4FD0-AD01-66DAD3A18B4F@fugue.com>
References: <66DC417B-23BC-4AF7-916B-5BAE7E5D9635@sky.uk> <ED3464BD-37A7-4B6F-8327-508B0CB76A3E@fugue.com> <21edfaff-8741-4f4f-a3d4-1aa88ede6935@getmailbird.com> <2970473C-046A-4FD0-AD01-66DAD3A18B4F@fugue.com>
User-Agent: Mailbird/2.6.10.0
X-Mailbird-ID: ae179431-f215-4138-b103-d6cc173a8952@getmailbird.com
X-Spam-Score-SW: -1.0 (-)
X-SW-Scan: 8a06d7bff6b5e39430a8e6115d0b1240
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/chfXZaZSs_TixDfHju05hIbqyw0>
X-Mailman-Approved-At: Sun, 15 Sep 2019 05:44:07 -0700
Subject: Re: [Add] [EXTERNAL] Re: Malware adopting DoH
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Sep 2019 10:30:42 -0000

No that's an argument for making an informed decision about what DNS service provider you use and possibly for being able to avoid limitations being imposed by the network you happen to be using at the time.

Using a VPN to access your DNS provider would achieve the same thing, as would using DoT or in many cases simply not using DHCP to decide your DNS provider.

If my an application is deciding which DNS service to use without my informed consent then even if it's using DoH it achieves none of the things you list.

Your list merely describes informed choice of DNS provider not any benefit uniquely inherent to DoH


-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden
On 14/09/2019 17:16:14, Ted Lemon <mellon@fugue.com> wrote:
On Sep 14, 2019, at 5:16 AM, Robert Mortimer <robm=40scramworks.net@dmarc.ietf.org [mailto:robm=40scramworks.net@dmarc.ietf.org]> wrote:
If google or any other TRR DoH provider start blocking malware by default surely that is filtering DNS which is the very problem that DoH is claiming to be solving?

The argument for DoH is that you can 
* reliably know who operates the resolver you are talking to
* know what the terms of service are
* choose your provider based on their terms of service
* not be forced to accept whatever terms service provider through which you are connecting at the moment insists upon, possibly with out telling you