Re: [DNSOP] [hrpc] Proposal for a side-meeting on services centralization at IETF 104 Prague

[Paul Vixie <[e-mail]>]

i've removed "[e-mail]" 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