Re: [DNSOP] extension of DoH to authoritative servers

Paul Vixie <paul@redbarn.org> Tue, 12 February 2019 23:32 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 095FF126C15 for <dnsop@ietfa.amsl.com>; Tue, 12 Feb 2019 15:32:39 -0800 (PST)
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=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 7DkGUGbtKVaa for <dnsop@ietfa.amsl.com>; Tue, 12 Feb 2019 15:32:37 -0800 (PST)
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 5893F126C01 for <dnsop@ietf.org>; Tue, 12 Feb 2019 15:32:37 -0800 (PST)
Received: from [IPv6:2001:559:8000:c9:14dc:261d:a3ba:1384] (unknown [IPv6:2001:559:8000:c9:14dc:261d:a3ba:1384]) (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 0A290892C6; Tue, 12 Feb 2019 23:32:37 +0000 (UTC)
To: David Conrad <drc@virtualized.org>
Cc: dnsop <dnsop@ietf.org>
References: <2019021215560470371417@cnnic.cn> <20190212083908.w5cwgtmypkjwmqnd@nic.fr> <ecfdb33d-7925-f762-6788-68b7a659a3d8@redbarn.org> <43FF2435-37C6-43B0-B97C-59D23AD2A9C2@virtualized.org> <873fe3e1-58e4-38a7-eb11-37509f9b7ff4@redbarn.org> <D01BFEEE-746D-4F30-A3CE-497D4AFA8CC5@fugue.com> <7cdbd8a8-2bf4-992e-3197-ca17e7352a5b@redbarn.org> <725FD25D-FCE9-4740-A001-79369AFDEB78@fugue.com> <d1f66089-1e78-15f6-269c-33ced12c2738@redbarn.org> <3C1FF728-2F31-4884-B7E9-55DF4E15AEB6@fugue.com> <cb9646e3-676d-c24f-240d-e0c8ed159e88@redbarn.org> <4C2F9639-6C22-4FB7-840B-0318B40C2193@fugue.com> <9e56da22-4fb5-1c68-3bfc-85283b0e8480@redbarn.org> <E2ABD9DC-668E-44BA-AB09-367C7B16C716@virtualized.org> <fa4a2570-f8bc-2694-1a27-f2795515520b@redbarn.org> <8B58EEF9-2669-47E3-B3D4-7993A1118C8C@virtualized.org>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <9e559ef1-7bb9-f53c-1543-fac92133bdac@redbarn.org>
Date: Tue, 12 Feb 2019 15:32:37 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.10
MIME-Version: 1.0
In-Reply-To: <8B58EEF9-2669-47E3-B3D4-7993A1118C8C@virtualized.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Kfyxi2CPBqJDu-HkYivstj_Jtlw>
Subject: Re: [DNSOP] extension of DoH to authoritative servers
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: Tue, 12 Feb 2019 23:32:39 -0000


David Conrad wrote on 2019-02-12 15:10:
> You missed my point.  The IETF declared NATs heretical and as a
> result, a zillion people did it in a zillion different ways, creating
> a huge mess.

i remember this. and i agree. had IAB said "this specification is
inadequate, let's get firewall traversal working before we publish",
rather than "it is heretical and must not be done", a lot of pain and
waste would have been avoided.

> ...  Lots of people are implementing sending/receiving DNS 
> queries/responses over HTTPS.

since i did it myself (https://github.com/BII-Lab/DNSoverHTTP) years
before DoH was thought of, i can scarcely disagree.

> DoH simply codifies one way of doing it so that network managers,
> software developers, etc., have a chance to develop management
> systems for it.


really? "simply"? i don't think it's that simple. here's the part of RFC 
8484 that i would have expected to cause a "discuss" event in IESG 
before allowing publication:

<<Two primary use cases were considered during this protocol's 
development.  These use cases are preventing on-path devices from 
interfering with DNS operations, ...>>

that's not a simple thing. IESG should have said, "that part is 
problematic, please make this protocol optional for the network 
operators and controllable their on-path devices."

by putting that text in and leaving it in, this becomes a political 
project not a technical one. IESG had the ability to say, please find a 
better way to solve this problem, that disenfranchises nobody.

as it happens, nothing stops a web browser or other such client from 
using DoT, and it's possible that the right answer was to say, DoT will 
answer every technical need that this RFC describes, but none of its 
political needs, and we don't want to be in the politics business.

to validate whether RFC 8484's goal is political, let's ponder whether 
the document would have been perfectly unhurt by the non-enumeration of 
this use case. i think yes. so, why mention it?

>> i'd like the same level of freedom when it comes to how DNS is
>> served.
> 
> Then force the folks on your network to install a cert so you can
> filter out DoH.  Contrary to your assertion, I doubt netflow will let
> you discriminate between good and evil. You have to have visibility
> to do that.
i have embedded devices which don't let me install certs inside them, 
and i don't think i'm alone. the general name for what you're describing 
is "web application firewall" and it simply breaks anything that won't 
cooperate -- which is the policy i'm going to need, if any so-called 
"public DNS" server shares a DoH responder address with any other 
service i care about. this remains to be seen. the market will help decide.

i'm surprised and fascinated by your vision of what my security needs 
are -- even though you have misstated them here -- but you're wrong on 
the facts, and the economics. if you are willing to spend the serious 
effort it would take to fully engage with the lived experience of modern 
CISO's, then we should take that topic up 1x1.

-- 
P Vixie