Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

Paul Vixie <paul@redbarn.org> Mon, 11 March 2019 18:12 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 4E48C13108C; Mon, 11 Mar 2019 11:12:49 -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, 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 A-5M4Od_k-L1; Mon, 11 Mar 2019 11:12:48 -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 4EBFB1310F4; Mon, 11 Mar 2019 11:12:45 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:6529:414d:1c66:203e] (unknown [IPv6:2001:559:8000:c9:6529:414d:1c66:203e]) (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 1F755892C6; Mon, 11 Mar 2019 18:12:45 +0000 (UTC)
To: nalini elkins <nalini.elkins@e-dco.com>
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Christian Huitema <huitema@huitema.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, "Ackermann, Michael" <mackermann@bcbsm.com>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <eea64b30-aad0-a030-5360-1b1484f1d0e3@huitema.net> <CAPsNn2WhjHSEHJUEL8GB6X0d24fkajgPnY4YgkOQbXjyxb5q8Q@mail.gmail.com> <e62efaf3-4a35-4a52-5ed4-dee2e7fafe72@huitema.net> <69f989ba-0939-b917-b586-9e3af3fb8b74@redbarn.org> <CAPsNn2XNCzgAdfJtxBVboAe+d6sbCiV2fZv9185wm+HN+3zRdg@mail.gmail.com> <BYAPR16MB279065EE519680E7FC9A637CEA480@BYAPR16MB2790.namprd16.prod.outlook.com> <CAPsNn2Up1AtJJCdmu_9NC4jfzc-8dtE+QjUzRxMBUwaN44gvOg@mail.gmail.com>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <76386691-c1aa-c48a-9b0d-67eb36a08a4f@redbarn.org>
Date: Mon, 11 Mar 2019 11:12:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.11
MIME-Version: 1.0
In-Reply-To: <CAPsNn2Up1AtJJCdmu_9NC4jfzc-8dtE+QjUzRxMBUwaN44gvOg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NlgmfM7Dypyz9axVQypVCGQc8LY>
Subject: Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients
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, 11 Mar 2019 18:12:50 -0000


nalini elkins wrote on 2019-03-11 10:26:
> Tiru,
> 
> Thanks for your comments.
> 
>  > Enterprise networks are already able to block DoH services,
i wonder if everyone here knows that TLS 1.3 and encrypted headers is 
going to push a SOCKS agenda onto enterprises that had not previously 
needed one, and that simply blocking every external endpoint known or 
tested to support DoH will be the cheaper alternative, even if that 
makes millions of other endpoints at google, cloudflare, cisco, and ibm 
unreachable as a side effect?

CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i 
blocked already (before DoH) so that's not a problem. but if google 
decides to support DoH on the same IP addresses and port numbers that 
are used for some API or web service i depend on, that web service is 
going to be either blocked, or forced to go through SOCKS. this will add 
considerable cost to my network policy. (by design.)

-- 
P Vixie