Subject: [Doh] ..I don't get it (the hate)

From: George Michaelson <[email-masked]>
Date: Tue, 26 Mar 2019 12:15:36 +0100

I have (fictionally) invented two new technologies. Lets call  them
"VPN" and "IP in IP"

at this point, every ISP in the IETF microphone queue wants to stand
up and say this has severe operational issues for them in running a
carriage service and "stop this nonsense"

the "DOH will cause me operational problems" thing, I simply don't understand.

 * I can write web pages with embedded IP addresses any time. I can
remove the DNS from my web calls

 * Nobody really knows what is flowing over the end-to-end any more,
given QUIC and like protocols.

This standard is a mechanism to define how to embed state in HTTP,
which means DNS traffic doesn't happen. But, DNS does or doesn't
happen *come what may* -we are arguing about a *standard* way to
specify how "not to do DNS" visibly.

I am not saying I'm in love with DOH (I ask myself what cache
poisoning risks there are in held state in the browser, and how far
outside a sandbox fetched data can extend) but, the .. "it is evil and
must die" side, I just don't understand.

The "DOH breaks privacy" and "centralization must be confronted"
questions, thats different. But, I am trying to think like a customer,
sending packets, and what I feel about the packets, and who gets to
say what is in them and what they are for.

This is (surely) between me, the browser vendor, and the website? Why
does the ISP have any say in this?

Not standardising this, is not going to stop people thinking about
ways to construct web site state which pass information in JSON form,
which informs which getURL() calls are made, and which demand
gethostbyname() and which do not invoe gethostbyname()

---

From: Joe Abley <[email-masked]>
Date: Tue, 26 Mar 2019 04:31:24 -0700

> does the ISP have any say in this?

The ISP (or equivalent actor) has the opportunity to have a say today.
Some deployment models would take this opportunity away.

I don't believe the concern is for sophisticated users who can make
informed choices. I can use a tor browser right now that also defeats
the ISP's opportunity to participate in the resolution process. That's
not controversial.

The contentious aspect is, I think, the potential for a majority of
end-users who are not sophisticated and hence are unable to make
informed decisions to have this behaviour changed for them.

It's not the existence of the mechanism, it's the potential scale of
the deployment.

Joe

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 26 Mar 2019 13:36:57 +0100

> informed decisions to have this behaviour changed for them.

And in a similar vein, unsophisticated end users who might change this
configuration deliberately, and then still expect their ISP to help them
out when they've got a problem.

I think the biggest enterprise concern is more around the balance between
users' privacy in one context (e.g. protecting dissidents) and user privacy
and security in other contexts (e.g. data exfiltration by malware).  I'm
concerned, and I believe others are as well, that while we're making gains
in the former, the loss in the latter may outweigh those gains by quite a
lot.  The malware on a user's system that is now able to reach its C&C
because its DNS queries cannot be blocked doesn't just put the user of that
computer at risk, but all the other users on that network as well.  And
there, again, it's a question of scale.  While it's possible for malware to
set up similar resolution systems today, if they do it stands out in ways
that can be detected and mitigated.  If they're hiding in the forest of all
the standard web browser traffic, that becomes a much more complex (and
therefore expensive) problem.

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Mar 2019 13:56:45 +0100

I think it’s a correct observation that the majority of end-users are not qualified to make security policy decisions at a fine-grained level.   It’s also the case that frequently end-users do not have the opportunity to make choices that they would make if they were available (e.g., Facebook, but without all the privacy violations).   But I think that’s not the right taxonomy.

I think the actual split is between devices that have to have on-device security policy enforcement, and devices that can’t.   My iPhone is roaming to networks with different policies all the time.   No matter how well-intentioned, the security policy of a particular network cannot protect my iPhone, because my iPhone talks to other networks.

So for devices like iPhones, a network-enforced security policy can only really cause harm: any good that it could have caused is voided by the fact that the network isn’t always there to protect it.

This is okay, because when I chose my iPhone, one of the reasons I chose it was that another entity would enforce a security policy on it that protects it from attack: the manufacturer, in this case Apple.   Apple has made a very deliberate decision to secure the iPhone in such a way that I can, with reasonable although not perfect confidence, trust that it will not be hacked by the network to which it connects.

On the other hand, my WeMo is wide open.   It doesn’t have any real security.   I’m sure we all know of examples of devices for which this is true.   Such devices tend not to move from network to network, and tend not to be seriously hardened against attack.

In order to protect my WeMo from attack, I need the network to strictly control what it communicates with.   This can to some degree be approximated by controlling DNS resolution.  But to be sure that it is controlled, the network also needs to do IP address filtering, and that filter needs to be controlled somehow.

As Eliot has demonstrated, it is possible to use DNS to control the hosts to which a host connects through a firewall, but it’s expensive, and it only works through the firewall.   That’s why we approximate this using DNS.

But if what we care about is controlling what hosts my iPhone connects to using DNS, the DNS resolver the iPhone uses has to be configured on the iPhone, and the connection to it has to be secure.   Controlling it at the network egress simply doesn’t solve that problem.

So when we are thinking about this problem, I think it’s important to be really clear about exactly what problem we are thinking about, and not confuse these two very different use cases and the very different control planes they require to address them.

> On Mar 26, 2019, at 12:31 PM, Joe Abley <[email-masked]> wrote:
>