Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Paul Vixie <paul@redbarn.org> Sat, 18 August 2018 21:46 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 DAA10130E06 for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 14:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 Qh7ilWLE9sDv for <dnsop@ietfa.amsl.com>; Sat, 18 Aug 2018 14:46:51 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAED31277D2 for <dnsop@ietf.org>; Sat, 18 Aug 2018 14:46:51 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62] (unknown [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2B96F892C7; Sat, 18 Aug 2018 21:46:51 +0000 (UTC)
Message-ID: <5B7893C9.7000703@redbarn.org>
Date: Sat, 18 Aug 2018 14:46:49 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: =?windows-1252?Q?Marek_Vavru=9Aa?= <mvavrusa=40cloudflare.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com>
In-Reply-To: <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GDzm2VAPWmwvpbCjzNUnIKASae4>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Sat, 18 Aug 2018 21:46:54 -0000


Ted Lemon wrote:
> DHCP authentication doesn't exist.   We already rejected a draft that
> described how to set up DoH with DHCP.   Yours is a little more
> complicated, but doesn't seem any less dangerous.   Before you go any
> farther on this, you might ask yourself a couple of questions:
>
> 1. Why is DoH being used?
> 2. What is the thread model that DoH is addressing?
> 3 How does adding this configuration mechanism impact DoH's ability to
> address that threat model?

the DoH use case is for web users and web apps who do not trust their 
network operator and who are not trusted by their network operator, so 
it's a policies-in-the-night model where data can be imported from The 
Web without approval or permission or control or observability by a 
network operator. it is in other words a thin DNS-only way to do what 
Tor does.

as a network operator, i oppose this thinking. i predict a long war in 
which web users and apps who want to use DoH to reach an external DNS 
resolver will be treated as attackers, and either banned or blocked. in 
some parts of the world such use will be illegal and even punishable, 
much as Tor is today.

this is what happened after edward snowden flew to hong kong: the 
pendulum swung so far the other way that many of us saw only absurdity.

the possibility that large CDN operators will colo a DOH endpoint with 
their high-value hosting, in order to discourage network operators from 
blocking it, raises the stakes. _i_ will block it. most corporate 
networks will block it in some form. some countries will block it. no 
DNS content will enter my network without having passed through my RPZ 
rules. if a CDN operator wants to play "chicken", i guess that we will.

-- 
P Vixie