Re: [Add] meeting hum: should the IETF take up this work?

Michael Sinatra <michael@brokendns.net> Tue, 23 July 2019 22:35 UTC

Return-Path: <michael@brokendns.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 0EB791203C2 for <add@ietfa.amsl.com>; Tue, 23 Jul 2019 15:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qQaGsu9WzLls for <add@ietfa.amsl.com>; Tue, 23 Jul 2019 15:35:49 -0700 (PDT)
Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (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 19907120352 for <add@ietf.org>; Tue, 23 Jul 2019 15:35:48 -0700 (PDT)
Received: from elwha.brokendns.net (elwha.brokendns.net [IPv6:2607:f2f8:a544:0:0:0:0:2]) by burnttofu.net (8.15.2/8.15.2) with ESMTPS id x6NMZhVp095208 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 18:35:44 -0400 (EDT) (envelope-from michael@brokendns.net)
Received: from Michaels-MBP.dhcp.lbnl.us (michaels-mbp.dhcp.lbnl.us [198.128.205.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id D0BD95E0DE; Tue, 23 Jul 2019 15:35:42 -0700 (PDT)
To: Rob Sayre <sayrer@gmail.com>, add@ietf.org, Barry Leiba <barryleiba.mailing.lists@gmail.com>
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com>
From: Michael Sinatra <michael@brokendns.net>
Message-ID: <be403a12-08e0-19dd-f62f-a34cec031b04@brokendns.net>
Date: Tue, 23 Jul 2019 15:35:36 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.6.2 (burnttofu.net [IPv6:2607:fc50:1:9d00:0:0:0:9977]); Tue, 23 Jul 2019 18:35:45 -0400 (EDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/EIYXzyS6bdOLFR-0MNJdeNi73_8>
Subject: Re: [Add] meeting hum: should the IETF take up this work?
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: Tue, 23 Jul 2019 22:35:51 -0000

On 7/23/19 3:09 PM, Rob Sayre wrote:
> Hi,
> 
> The IETF shouldn't take up work in reaction to non-technical (aka 
> "policy") concerns about imminent deployment of an approved RFC. In this 
> case, it's DoH (https://tools.ietf.org/html/rfc8484).
> 
> Mozilla's presentation accurately stated that DNS is no longer an 
> effective control surface. It can't be, given that HTTPS is ubiquitous, 
> and one can use it to tunnel any protocol.

1. A primary motivation, according to previous discussions on this and 
other mailing lists, for DoH is predicated on the *significant 
effectiveness* of DNS filtering by oppressive governments.

2. A number of us have pointed out that DNS filtering is commonly used, 
also quite effectively, by good guys, and that using DoH by default can 
create noticeable collateral damage.

3. You have stated that DNS filter was never that effective, which then 
calls into question the primary motivation for DoH.  See #1.

Such an argument--that DNS filtering works for bad uses but doesn't work 
for good uses--uncannily mirrors the argument for weakening encryption: 
Terrorists won't be able to use encryption, but law-abiding citizens can 
still rest assured that online banking and e-commerce will be *just as 
secure* as it was before encryption protocols were watered down with 
backdoors.

Neither argument holds much water.

michael