Re: [hrpc] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
Paul Vixie <paul@redbarn.org> Thu, 14 March 2019 19:50 UTC
Return-Path: <paul@redbarn.org>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054CE1310F7 for <hrpc@ietfa.amsl.com>; Thu, 14 Mar 2019 12:50:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Fsyf5flvRUco for <hrpc@ietfa.amsl.com>; Thu, 14 Mar 2019 12:50:49 -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 748FB131133 for <hrpc@irtf.org>; Thu, 14 Mar 2019 12:50:49 -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 09571892C6; Thu, 14 Mar 2019 19:50:49 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org, hrpc@irtf.org
Cc: doh@ietf.org
Date: Thu, 14 Mar 2019 19:50:46 +0000
Message-ID: <5105495.cfdlLhXNj9@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <CAJVAGYg+AmaK4AgkrioMt1Z_UGVZdnsNuNasnouuxUzaU7kMxA@mail.gmail.com>
References: <20190311170218.o5hitvysuefhjjxk@nic.fr> <4425132.CsHbCTgi9Z@linux-9daj> <CAJVAGYg+AmaK4AgkrioMt1Z_UGVZdnsNuNasnouuxUzaU7kMxA@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/hrpc/fm0gJpxeCPW_G9b1uSWBWauzWkE>
Subject: Re: [hrpc] [DNSOP] Proposal for a side-meeting on services centralization at IETF 104 Prague
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "mail@nielstenoever.net" <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2019 19:50:51 -0000
i've removed "dns-privacy@ietf.org" from the CC headers, at the WG chair's request. note, the main topic of this message is DNS privacy's implications. On Thursday, 14 March 2019 17:50:44 UTC Vinicius Fortuna [vee-NEE-see.oos] wrote: > Paul, I'm trying to understand your scenario. > > If you ran your own DoH server in your network (doing RDNS or whatnot), and > the DoH server is distributed to clients via DHCP + a protocol upgrade > mechanism, would that address the concerns you are listing? > > Vinicius Fortuna no. the new risk intended by DoH comes from its expected ubiquity. two of its design assumptions are wrong. one wrong assumption is that all users and apps operating inside my network deserve rdns service from third parties that is invisible to me (as network operator) and which is therefore subject to neither my surveillance nor my control. it turns out that some users are intruders and some apps are malware, and i do not want them to have the capability of invisible third party rdns. the second wrong assumption is that all on-path interferers have ill intent and do not deserve to surveil or control their network's rdns. as a parent, my interest in monitoring and control of the control plane used by my family, including rdns, is not a matter to be litigated against IETF consensus. the same thing happens at a larger scale in my corporate network. so, no DoH service i can add would have any impact on the intended risks of DoH. i may offer it anyway, for clients who can't use DoT. but for my actual purposes both a user of networks and an operator of networks, DoT is both sufficient and better. my costs to mitigate the risks intended by DoH will in some cases be cheap, like enumerating the so-called "public DNS" providers who offer it, and blocking them at my IP firewall. DoH risk mitigation costs will be much higher for me when DoH is offered by an IP that i have other business with, for example if i need access to a google API or service, and the same IP also offers DoH. there, i'll have to run a tls proxy, and break any client who tries to use outbound TCP/443 directly. many people here have mistakenly asserted that i had that risk anyway, and that this mitigation cost should already be on my ledger. this is mistaken for two reasons, both of which owe to security economics. first, because some of my networks have an outbound TCP/443 whitelist which may have included IP addresses i previously thought i could trust not to offer invisible third party rdns to intruders or malware (or children) on my network. second, because some of my networks only close the barn door after badness has passed through -- that is, the IP blacklist is amended after a detection event, since whitelisting wasn't feasible. defense that only works in the future is still quite a bit better than defense that will not work in the future. DoH, by intending to be invisible inside flows i already accept, will raise my defense costs, forever. so, the costs of proxying TCP/443 to well known IP addresses was not already on my ledger, but must be now, and will have far-reaching effects. not all agents (users and apps) inside my network are friendly and trusted, nor can they be expected to use DoH only when MDM tells them it is ok. not all network operators who monitor or control their rdns are unfriendly or untrustworthy. DoH is intended to be, and is, a security economics disaster for edge network operators. vixie
- [hrpc] Proposal for a side-meeting on services ce… Stephane Bortzmeyer
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Vittorio Bertola
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Allison Mankin
- Re: [hrpc] Proposal for a side-meeting on service… Stephane Bortzmeyer
- Re: [hrpc] Proposal for a side-meeting on service… Stephane Bortzmeyer
- Re: [hrpc] [Doh] Proposal for a side-meeting on s… Mark Nottingham
- Re: [hrpc] [Doh] Proposal for a side-meeting on s… Stephane Bortzmeyer
- Re: [hrpc] Proposal for a side-meeting on service… Vittorio Bertola
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Paul Vixie
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Ted Lemon
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Paul Vixie
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Ralf Weber
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Stephen Farrell
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Ralf Weber
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Ted Lemon
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Vinicius Fortuna [vee-NEE-see.oos]
- Re: [hrpc] [DNSOP] Proposal for a side-meeting on… Paul Vixie
- Re: [hrpc] [Doh] [DNSOP] Proposal for a side-meet… Vittorio Bertola