Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

Paul Vixie <paul@redbarn.org> Mon, 15 July 2019 15:14 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8533D120167 for <dnsop@ietfa.amsl.com>; Mon, 15 Jul 2019 08:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 biToO09rqiOU for <dnsop@ietfa.amsl.com>; Mon, 15 Jul 2019 08:14:35 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7937012011B for <dnsop@ietf.org>; Mon, 15 Jul 2019 08:14:35 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 52701892E8; Mon, 15 Jul 2019 15:14:35 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Rob Sayre <sayrer@gmail.com>
Cc: dnsop@ietf.org
Date: Mon, 15 Jul 2019 15:14:35 +0000
Message-ID: <8499859.s69PqOT0jb@linux-9daj>
Organization: none
In-Reply-To: <CAChr6SyM3LSgAdu5+SJGq-n=+AZc7M44BVSru_EZgf9svBHo3w@mail.gmail.com>
References: <CAChr6SyVmgMpD6Cd=m2Z03nts-Bv9ZVgJkG8oaj_jzwYMUZuCg@mail.gmail.com> <3220557.rvQTihJl8x@linux-9daj> <CAChr6SyM3LSgAdu5+SJGq-n=+AZc7M44BVSru_EZgf9svBHo3w@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6M0aDlmv9iUaKX_8tI_jZW1-roo>
Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 15:14:38 -0000

On Monday, 15 July 2019 02:17:04 UTC Rob Sayre wrote:
> On Sun, Jul 14, 2019 at 6:59 PM Paul Vixie <paul@redbarn.org> wrote:
> > ...
> 
> I'm surprised that you seem to view DoH as a problem. I mean, everyone knows
> that TLS and IPSEC are compromised by determined attackers, ...

if you know a way that modern TLS 1.3 can be compromised by MiTM, i'd like to 
know more. a lot of us are moving from MiTM to explicit outbound proxy with an 
internally trusted key in order to fulfill our corporate or regulatory 
obligations.

> but I didn't know
> it was a continued sore spot. If you have more to say, I would like to hear
> it.

the introduction of the DoH RFC explains that this protocol is designed to 
prevent interference by on-path actors in dns operations. i am a committed, 
determined on-path interferer, both for parental controls at home and 
corporate controls at $dayjob. see https://dnsrpz.info/ for background, but 
note that i am not the first to do something like RPZ at wide scale, nor is 
RPZ the only known way to use network-level DNS to protect end users and apps.

i could go (and have gone) on at great length about the pratfalls of DoH, but 
instead i'll sum up by saying that DoH is designed to increase the costs of an 
activity i MUST pursue, and it ignorantly lumps together private networks like 
home or corporate, public networks like coffee shops or ISP's, and networks in 
authoritarian places like china and turkey. i despise this ignorance entirely.

see also: 

https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/a/d-id/1333088

my best imagined outcome is mozilla saying oops, DoT will be fine, we're 
taking DoH out. because internet communications has always relied on revocable 
cooperation, consisting both of the willingness to speak a protocol, and the 
willingness to permit it through gateways one operates. by deliberately 
denying network operators the ability to withhold permission, DoH is an attack 
on the cooperative substrate of the internet itself.

-- 
Paul