Re: [DNSOP] extension of DoH to authoritative servers

Paul Vixie <paul@redbarn.org> Tue, 12 February 2019 21:48 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 B6970130DC2 for <dnsop@ietfa.amsl.com>; Tue, 12 Feb 2019 13:48:37 -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 0Yk1c9Or4hdC for <dnsop@ietfa.amsl.com>; Tue, 12 Feb 2019 13:48:36 -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 34AF712F1A6 for <dnsop@ietf.org>; Tue, 12 Feb 2019 13:48:36 -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 87D55892C6; Tue, 12 Feb 2019 21:48:35 +0000 (UTC)
To: Ted Lemon <mellon@fugue.com>
Cc: David Conrad <drc@virtualized.org>, 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>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <cb9646e3-676d-c24f-240d-e0c8ed159e88@redbarn.org>
Date: Tue, 12 Feb 2019 13:48:36 -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: <3C1FF728-2F31-4884-B7E9-55DF4E15AEB6@fugue.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Z4E8_Op06eIJOwbb-9m79HE_xwo>
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 21:48:38 -0000


Ted Lemon wrote on 2019-02-12 13:00:
> ...
> 
> I still feel like we are talking past each other.
> 
> What I am saying is that there are a set of different mechanisms, all of 
> which use port 443, in order to avoid being subjected to your control 
> plane.   DoH is in principle one of these.   We do not disagree about 
> this, as far as I can tell.
> 
> What I think we differ on is the idea that, in the absence of these 
> “political tacticians” of whom you speak, that this problem would not exist.
> 
> What I am trying to point out is that the situation with DoH is a 
> symptom of the problem you are not talking about, not the only instance 
> of it.
> 
> You seem to be asserting that DoH is special among all other misuses of 
> port 443.   But you haven’t explained why it is special.   This is what 
> I was trying to tease out with my initial response to what you said.

i may have been too brief. however, i reject this false equivalence.

when a new flow or pattern of flows shows up to distant tcp/443 
responders, this is detectable. if what's detected exceeds thresholds, 
or if it is found to coincide with any other behaviour change, then it 
can be investigated, and perhaps made the subject of new policy. no 
security is perfect and we can't demand it. what we have is temporary 
equilibriums that appropriately match investments and known risks.

DoH _specifically_ evades this, by looking as much as possible like 
other traffic to IP addresses shared by a lot of existing traffic. this 
means the only way to maintain the risk:cost balance of pre-DoH is to 
inspect every flow. many network operators can't afford this or can't 
otherwise do it. those who can and do, can be expected to be grumpy 
about it having their risks and costs increased for political reasons. 
those who can't or don't, can be expected to be grumpy about losing more 
of what little control or visibility they had, for political reasons.

google, ibm, cloudflare, cisco, and other so-called "public dns" 
providers will at some point choose whether to offer DoH from shared 
addresses, making those shared addresses into risks that the rest of us 
have to manage differently; or whether to dedicate DoH to well known 
addresses that can be outright blocked. in the later case, existing 
anomaly detection and post-facto investigations and policy shifts will 
continue to be good enough.

and that's why DoH is special.

(five paragraphs elided.)

-- 
P Vixie