4 ms·

I think the VPN vs DoH argument is a fallacy. You could argue the same way for things like telnet vs ssh and it would make just as little sense. In addition a V

by karasu 7y ago

I think the VPN vs DoH argument is a fallacy. You could argue the same way for things like telnet vs ssh and it would make just as little sense. In addition a VPN is much more complex than simply using DoH or DoT. DoH is also not meant to "hide" what you're doing as much as it is about enabling you to protect your DNS queries from manipulation. The only difference to the more direct approach (DoT) here is that DoH acknowledges the reality we live in where networks where DoT makes the most sense block anything but http/https traffic.

cbzbc 7y ago
The flip side is that on a local level (your own network) you want to be able to block all sorts of traffic for entirely good reasons.
- Ajedi32 7y ago
  The problem is that it's not realistic to expect client machines to be able to distinguish between blocking for "good reasons" or "bad reasons". The network isn't (usually) under the user's control, and as a result any reasonable threat model for software running on client machines should assume the network is actively malicious. Ultimately, I think any sort of content blocking is going to have to happen on client machines. Or at least via a mechanism which depends the client machine's active cooperation. Anything less just opens users up to interference from malicious third parties.
  - cbzbc 7y ago
    On the flip side; the client device is increasingly outside the control of the user (phones, smart speakers, TVs etc). So there's the question of how a user protects themselves against a device that may be actively or incidentally malicious. > The network isn't (usually) under the user's control, and as a result any reasonable threat model for software running on client machines should assume the network is actively malicious. Yes, but there is nothing about DoH that solves this in any way.
  - zzzcpan 7y ago
    Network is under user control, pretty much all devices require active cooperation to connect device's internal network to any external network, it doesn't happen on its own.
throw0101a 7y ago
> I think the VPN vs DoH argument is a fallacy. You could argue the same way for things like telnet vs ssh and it would make just as little sense. I do not see how the two are equivalent. DoH does not help you at at all if your browser is going to go to an IP that is on a watchlist. That is the author's (and Paul Vixie's point). HTTPS does protect exact content (like SSH), but the fact that you are going to (say) wikipedia.org, eff.org, or torproject.org, is much more difficult to hide because at the end of the day, if you're not using VPN, the network operator can see where your Layer 3 addresses are going to and can make inferences about your actions. And in some places inferences are 'good enough' to get you in trouble, or at least flagged for further monitoring. > DoH is also not meant to "hide" what you're doing as much as it is about enabling you to protect your DNS queries from manipulation. Technically speaking, if you're not getting DNSSEC signed results back, you're also trusting your DoH provider to not manipulate records. ;)
- karasu 7y ago
  > DoH does not help you at at all if your browser is going to go to an IP that is on a watchlist. That is the author's (and Paul Vixie's point). If that's the aim then I have to concur that DoH does nothing here. This is why I dislike the way Mozilla touts DoH as a privacy feature, because that's not what it (primarily) should be about, as far as I'm concerned. > Technically speaking, if you're not getting DNSSEC signed results back, you're also trusting your DoH provider to not manipulate records. ;) Agreed. But that's exactly why you can pick a trusted resolver, right? One that you trust to correctly validate DNSSEC for you, so you simply trust the AD bit in the response instead of doing all this on each and every client. And one that you trust not to mess with answers in general. Without either DoT or DoH, you are basically forced to validate DNSSEC on every Client, which seems like a waste.
  - throw0101a 7y ago
    > Without either DoT or DoH, you are basically forced to validate DNSSEC on every Client, which seems like a waste. Part of Vixie's talk was about the changing nature/position of the recursive resolver: when he started DNS stuff in 1988, it was often the case that there was a resolver right on the subnet that you were on, often living on the default gateway. As time has gone on, it started moving "up" closer to the cloud (as we now call it): to being building-wide, then to the campus, and now generally the ISP. (Though local CPE routers have a caching resolver nowadays, they often go to the ISP's service.) Now we're talking about having DNS 'in the cloud' (i.e., Internet) from some distant provider, often close (network/latency-wise) to the service that we will eventually connecting to once we get the look-up from.

by karasu 7y ago

cbzbc 7y ago

The flip side is that on a local level (your own network) you want to be able to block all sorts of traffic for entirely good reasons.

Ajedi32 7y ago
The problem is that it's not realistic to expect client machines to be able to distinguish between blocking for "good reasons" or "bad reasons". The network isn't (usually) under the user's control, and as a result any reasonable threat model for software running on client machines should assume the network is actively malicious. Ultimately, I think any sort of content blocking is going to have to happen on client machines. Or at least via a mechanism which depends the client machine's active cooperation. Anything less just opens users up to interference from malicious third parties.
- cbzbc 7y ago
  On the flip side; the client device is increasingly outside the control of the user (phones, smart speakers, TVs etc). So there's the question of how a user protects themselves against a device that may be actively or incidentally malicious. > The network isn't (usually) under the user's control, and as a result any reasonable threat model for software running on client machines should assume the network is actively malicious. Yes, but there is nothing about DoH that solves this in any way.
- zzzcpan 7y ago
  Network is under user control, pretty much all devices require active cooperation to connect device's internal network to any external network, it doesn't happen on its own.

throw0101a 7y ago

> I think the VPN vs DoH argument is a fallacy. You could argue the same way for things like telnet vs ssh and it would make just as little sense. I do not see how the two are equivalent. DoH does not help you at at all if your browser is going to go to an IP that is on a watchlist. That is the author's (and Paul Vixie's point). HTTPS does protect exact content (like SSH), but the fact that you are going to (say) wikipedia.org, eff.org, or torproject.org, is much more difficult to hide because at the end of the day, if you're not using VPN, the network operator can see where your Layer 3 addresses are going to and can make inferences about your actions. And in some places inferences are 'good enough' to get you in trouble, or at least flagged for further monitoring. > DoH is also not meant to "hide" what you're doing as much as it is about enabling you to protect your DNS queries from manipulation. Technically speaking, if you're not getting DNSSEC signed results back, you're also trusting your DoH provider to not manipulate records. ;)

karasu 7y ago
> DoH does not help you at at all if your browser is going to go to an IP that is on a watchlist. That is the author's (and Paul Vixie's point). If that's the aim then I have to concur that DoH does nothing here. This is why I dislike the way Mozilla touts DoH as a privacy feature, because that's not what it (primarily) should be about, as far as I'm concerned. > Technically speaking, if you're not getting DNSSEC signed results back, you're also trusting your DoH provider to not manipulate records. ;) Agreed. But that's exactly why you can pick a trusted resolver, right? One that you trust to correctly validate DNSSEC for you, so you simply trust the AD bit in the response instead of doing all this on each and every client. And one that you trust not to mess with answers in general. Without either DoT or DoH, you are basically forced to validate DNSSEC on every Client, which seems like a waste.
- throw0101a 7y ago
  > Without either DoT or DoH, you are basically forced to validate DNSSEC on every Client, which seems like a waste. Part of Vixie's talk was about the changing nature/position of the recursive resolver: when he started DNS stuff in 1988, it was often the case that there was a resolver right on the subnet that you were on, often living on the default gateway. As time has gone on, it started moving "up" closer to the cloud (as we now call it): to being building-wide, then to the campus, and now generally the ISP. (Though local CPE routers have a caching resolver nowadays, they often go to the ISP's service.) Now we're talking about having DNS 'in the cloud' (i.e., Internet) from some distant provider, often close (network/latency-wise) to the service that we will eventually connecting to once we get the look-up from.