3 ms·

> (a) Bottom-up DNS security can continue to succeed to the point where it links resolvers and caches to authority servers Even if that would happen, the clien

> (a) Bottom-up DNS security can continue to succeed to the point where it links resolvers and caches to authority servers Even if that would happen, the client would have no way to know if all the links were indeed secured. And even it would know it, it would have no way to know if any of the resolvers in those links forged a DNS response. With DNSSEC the client can verify that the response is indeed authentic. > (b) Regardless of whether it does, the costs attackers incur against DoH-protected hosts might be wildly higher than the benefits (the risk-of-failure-adjusted value of a misissuance via a DNS attack). Actually, it can be profitable for the DoH-protected hosts themselves to forge DNS responses, no attacker is needed. There are many consumer ISPs that do that already to display advertisements, collect statistics or straight up hijack domain names (e.g. due to piracy laws). DoH does nothing to prevent that, while a client resolver with DNSSEC support does protect against that. In fact, DNSSEC can work just as well with DoH, which is what I do on my laptop. These two technologies are not mutually exclusive and I see no reason why we can't use both at the same time.

tptacek 4y ago
What does it matter if the client knows or doesn't know the whole chain from the resolver to all its peers? There's nothing the client can do about it. DNS data is either hard to spoof (even now, that's the case) or it isn't. This idea that bottom-up DNS security is suspect because the client can't verify the whole chain would be easier to take if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server. This just isn't a real problem.
- wizeman 4y ago
  > What does it matter if the client knows or doesn't know the whole chain from the resolver to all its peers? There's nothing the client can do about it. If the client expected all the links to be secured (which is what you propose with a bottom-up security model) and if it would know whether they are or not, then it could fail to resolve if any link is not currently secured, if the user so desired. In your bottom-up security model proposal, this would protect against any external man-in-the-middle attack in the entire chain (but not an attacker within the chain). If the client doesn't know if all links are secured, then it is vulnerable as long as any link in the chain can be attacked (except for its own link), not to mention of course, by attackers within the chain as well. Since it has no way to know whether it was attacked or not, it has no way to prevent forged responses. > DNS data is either hard to spoof (even now, that's the case) It's really not hard. Otherwise, this page wouldn't list ongoing cases that affect millions of users right now, every single day: https://en.wikipedia.org/wiki/DNS_hijacking https://en.wikipedia.org/wiki/DNS_hijacking > if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server. Maybe on your system, not mine. If you use a local caching resolver with DNSSEC support (and why wouldn't you, unless you're using a microcontroller with close to zero resources?) then no application on your local system will get a forged response from domains with DNSSEC support (unless it was attacked at the source, origin DNS server or at the TLD level, of course, no way to prevent that), regardless of what your DNS server does or pretends to be doing, or any other DNS server in the chain, or even an external attacker that tries to attack any link in the chain, for that matter. You could also implement a DNS resolver with DNSSEC support on your browser, if you really wanted. But a local caching resolver is an even more generic solution, as it protects all local applications, not just your browser.
  - tptacek 4y ago
    First: the page you're citing talks (1) about stub-to-cache DNS lookups that DNSSEC doesn't protect at all, but DoH does (again: DNSSEC collapses down to the "authenticated data" bit in the ISP-controlled last mile) and (2) about "hijacks" that are actually registrar ATOs. Second: whatever weird thingy your system does, I respect it, but it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon. People love to point out that they can just run their own DNS server on their Linux box, which is obviously true, because that's how ISPs run DNS servers, too. I'm suitably impressed with your sysop ability, but I don't know what that has to do with Internet security.
    - wizeman 4y ago
      > the page you're citing talks (1) about stub-to-cache DNS lookups that DNSSEC doesn't protect at all, but DoH does Both DNSSEC and DoH can protect against DNS hijacking. DNSSEC can give you end-to-end protection if you use a DNSSEC-enabled resolver and the domain supports DNSSEC, while DoH can only protect one link in the chain, no matter what you do. > whatever weird thingy your system does, I respect it What is weird about running a local caching resolver? Most modern Linux systems do that, as far as I know. I simply use one that does DNSSEC verification by default. I don't see why Android/iOS phones or Windows systems wouldn't be able to do that by default in 2022, if their developers really wanted to implement that. > it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon. Yeah, not with that attitude :)
      - tptacek 4y ago
        Not with any attitude: what you and the phone sysadmins propose is, effectively, to eliminate all shared DNS caching from the Internet. A beautiful dream! But that's all it is. That no mainstream operating system in the world does this is all the evidence I need to dispose of this part of the argument.
        4y ago

tptacek 4y ago

What does it matter if the client knows or doesn't know the whole chain from the resolver to all its peers? There's nothing the client can do about it. DNS data is either hard to spoof (even now, that's the case) or it isn't. This idea that bottom-up DNS security is suspect because the client can't verify the whole chain would be easier to take if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server. This just isn't a real problem.

wizeman 4y ago
> What does it matter if the client knows or doesn't know the whole chain from the resolver to all its peers? There's nothing the client can do about it. If the client expected all the links to be secured (which is what you propose with a bottom-up security model) and if it would know whether they are or not, then it could fail to resolve if any link is not currently secured, if the user so desired. In your bottom-up security model proposal, this would protect against any external man-in-the-middle attack in the entire chain (but not an attacker within the chain). If the client doesn't know if all links are secured, then it is vulnerable as long as any link in the chain can be attacked (except for its own link), not to mention of course, by attackers within the chain as well. Since it has no way to know whether it was attacked or not, it has no way to prevent forged responses. > DNS data is either hard to spoof (even now, that's the case) It's really not hard. Otherwise, this page wouldn't list ongoing cases that affect millions of users right now, every single day: https://en.wikipedia.org/wiki/DNS_hijacking https://en.wikipedia.org/wiki/DNS_hijacking > if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server. Maybe on your system, not mine. If you use a local caching resolver with DNSSEC support (and why wouldn't you, unless you're using a microcontroller with close to zero resources?) then no application on your local system will get a forged response from domains with DNSSEC support (unless it was attacked at the source, origin DNS server or at the TLD level, of course, no way to prevent that), regardless of what your DNS server does or pretends to be doing, or any other DNS server in the chain, or even an external attacker that tries to attack any link in the chain, for that matter. You could also implement a DNS resolver with DNSSEC support on your browser, if you really wanted. But a local caching resolver is an even more generic solution, as it protects all local applications, not just your browser.
- tptacek 4y ago
  First: the page you're citing talks (1) about stub-to-cache DNS lookups that DNSSEC doesn't protect at all, but DoH does (again: DNSSEC collapses down to the "authenticated data" bit in the ISP-controlled last mile) and (2) about "hijacks" that are actually registrar ATOs. Second: whatever weird thingy your system does, I respect it, but it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon. People love to point out that they can just run their own DNS server on their Linux box, which is obviously true, because that's how ISPs run DNS servers, too. I'm suitably impressed with your sysop ability, but I don't know what that has to do with Internet security.
  - wizeman 4y ago
    > the page you're citing talks (1) about stub-to-cache DNS lookups that DNSSEC doesn't protect at all, but DoH does Both DNSSEC and DoH can protect against DNS hijacking. DNSSEC can give you end-to-end protection if you use a DNSSEC-enabled resolver and the domain supports DNSSEC, while DoH can only protect one link in the chain, no matter what you do. > whatever weird thingy your system does, I respect it What is weird about running a local caching resolver? Most modern Linux systems do that, as far as I know. I simply use one that does DNSSEC verification by default. I don't see why Android/iOS phones or Windows systems wouldn't be able to do that by default in 2022, if their developers really wanted to implement that. > it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon. Yeah, not with that attitude :)
    - tptacek 4y ago
      Not with any attitude: what you and the phone sysadmins propose is, effectively, to eliminate all shared DNS caching from the Internet. A beautiful dream! But that's all it is. That no mainstream operating system in the world does this is all the evidence I need to dispose of this part of the argument.
      - 4y ago