5 ms·

I think you are incorrect here. DNSSEC protects from the root servers' (.) keys downward. If you have a compliant DNSSEC resolver it should authenticate the ent

I think you are incorrect here. DNSSEC protects from the root servers' (.) keys downward. If you have a compliant DNSSEC resolver it should authenticate the entire chain using the pre-shared keys for the root domain. For a MITM attack to work in this scenario, the attacker would have to first get fake keys for the root domain (that normally come with the OS) into your computer, at which point not even DNS over anything would work because they should be able to install TLS certs too. As far as I know, all these DNS-over-TLS flavors' advantage is that they prevent eavesdropping, not spoofed traffic (because DNSSEC can do that too as per my explanation above).

tptacek 6y ago
The parent comment is more right than not: end-systems in fact don't perform DNSSEC validation, but rather rely on their DNS servers to do it for them. On the network path between an end-system and its DNS server, no cryptography is deployed to protect DNS records; rather, a single bit in the header signals to DNS resolvers that some DNSSEC validation has been performed, somewhere. Along that network path, any middlebox can tamper with the DNS. It's not an academic concern, because the two most common modes of deployment for DNS are "with ISP DNS servers", in which case one of your most important and active DNS adversaries is on-path, and "with services like 8.8.8.8", in which case the whole Internet is between you and the thing that validated DNSSEC for you. It's not a good system, and it's true that DoH does a better job at addressing this problem.
- kilburn 6y ago
  That totally makes sense. Thanks for the explanation!
- tialaramex 6y ago
  It's certainly true that if you want your resolver to live on a separate node that you trust, yet there's a network you don't trust between you and that node, DPRIVE attempts to solve that and DNSSEC does not. But without DNSSEC a middlebox still gets to tamper anyway, since there's no authenticity of the answers you receive, you're just moving your trustworthy source of these potentially bogus answers for whatever that's worth. Thomas believes your ISP is "one of your most important and active DNS adversaries" and yet astonishingly he trusts them to provide you with authentic DNS answers. If you do local validation, which you're free to, DNSSEC solves the problem. If you do remote validation but you trust the remote DNS server to do that on your behalf correctly, DNSSEC solves the problem and then any DPRIVE protocol brings those correct answers home intact. If you believe there are certainly authentic answers where Google is (I have a lot of used iron available, central Paris area, it's in the form of a big tower so you can't miss it, buyer collects) then just DPRIVE lets you get their authentic answers. Notice that Google does not warrant that this is true, and "where Google is" might mean a data centre controlled by your country's censors.
  - tptacek 6y ago
    I don't understand why you think I trust residential ISPs with the DNS, since that's the opposite of what I believe --- residential ISPs are actively monetizing the DNS.
    - tialaramex 6y ago
      The example you cited is "with ISP DNS servers". But if you in fact don't trust them, DPRIVE on its own doesn't help you. Same way upgrading from HTTP to HTTPS doesn't prevent you getting misinformation from Conservapedia. The answers on the site are bad, so ensuring nobody "tampers" with those bad answers doesn't really help you. DPRIVE is good stuff, and one of the things that great about it is that it unsticks the deployability problem for DNSSEC client validation, but I'm guessing that's not the part you're keen on.
      - tptacek 6y ago
        I'm lost. The point of using DOH (which isn't DPRIVE, which is itself a moribund project) is not using ISP DNS servers in the first place. Can you maybe rephrase this somehow?
        tialaramex 6y ago
        DPRIVE is the working group that owns all the ongoing DNS privacy work, including RFC 7226 (upon which RFC 8484 DoH depends and a bis document for which is probably to be expected next year) and the forthcoming BCP document describing best practices for all these privacy preserving DNS services. The existence of a short WG to spin up, consume a good first draft and spit out a single DoH document RFC 8484 doesn't change that. I have no idea which "moribund project" you're referring to and I doubt it's relevant here. As to "not using ISP DNS servers in the first place" I guess you do not consider Comcast to be an ISP? Or perhaps you didn't hear. Both Chrome and Firefox will automatically give Comcast's customers Comcast DNS over HTTPS. Mozilla secured a TRR agreement from Comcast in exchange, and presumably Google feels that this agreement plus any undisclosed paperwork from Comcast that they were shown as part of their onboarding process is enough to likewise trust it automatically in Chrome. We expect to see more ISPs doing this over the next few years. If you cannot beat them, join them, eh?

tptacek 6y ago

The parent comment is more right than not: end-systems in fact don't perform DNSSEC validation, but rather rely on their DNS servers to do it for them. On the network path between an end-system and its DNS server, no cryptography is deployed to protect DNS records; rather, a single bit in the header signals to DNS resolvers that some DNSSEC validation has been performed, somewhere. Along that network path, any middlebox can tamper with the DNS. It's not an academic concern, because the two most common modes of deployment for DNS are "with ISP DNS servers", in which case one of your most important and active DNS adversaries is on-path, and "with services like 8.8.8.8", in which case the whole Internet is between you and the thing that validated DNSSEC for you. It's not a good system, and it's true that DoH does a better job at addressing this problem.

kilburn 6y ago
That totally makes sense. Thanks for the explanation!
tialaramex 6y ago
It's certainly true that if you want your resolver to live on a separate node that you trust, yet there's a network you don't trust between you and that node, DPRIVE attempts to solve that and DNSSEC does not. But without DNSSEC a middlebox still gets to tamper anyway, since there's no authenticity of the answers you receive, you're just moving your trustworthy source of these potentially bogus answers for whatever that's worth. Thomas believes your ISP is "one of your most important and active DNS adversaries" and yet astonishingly he trusts them to provide you with authentic DNS answers. If you do local validation, which you're free to, DNSSEC solves the problem. If you do remote validation but you trust the remote DNS server to do that on your behalf correctly, DNSSEC solves the problem and then any DPRIVE protocol brings those correct answers home intact. If you believe there are certainly authentic answers where Google is (I have a lot of used iron available, central Paris area, it's in the form of a big tower so you can't miss it, buyer collects) then just DPRIVE lets you get their authentic answers. Notice that Google does not warrant that this is true, and "where Google is" might mean a data centre controlled by your country's censors.
- tptacek 6y ago
  I don't understand why you think I trust residential ISPs with the DNS, since that's the opposite of what I believe --- residential ISPs are actively monetizing the DNS.
  - tialaramex 6y ago
    The example you cited is "with ISP DNS servers". But if you in fact don't trust them, DPRIVE on its own doesn't help you. Same way upgrading from HTTP to HTTPS doesn't prevent you getting misinformation from Conservapedia. The answers on the site are bad, so ensuring nobody "tampers" with those bad answers doesn't really help you. DPRIVE is good stuff, and one of the things that great about it is that it unsticks the deployability problem for DNSSEC client validation, but I'm guessing that's not the part you're keen on.
    - tptacek 6y ago
      I'm lost. The point of using DOH (which isn't DPRIVE, which is itself a moribund project) is not using ISP DNS servers in the first place. Can you maybe rephrase this somehow?
      - tialaramex 6y ago
        DPRIVE is the working group that owns all the ongoing DNS privacy work, including RFC 7226 (upon which RFC 8484 DoH depends and a bis document for which is probably to be expected next year) and the forthcoming BCP document describing best practices for all these privacy preserving DNS services. The existence of a short WG to spin up, consume a good first draft and spit out a single DoH document RFC 8484 doesn't change that. I have no idea which "moribund project" you're referring to and I doubt it's relevant here. As to "not using ISP DNS servers in the first place" I guess you do not consider Comcast to be an ISP? Or perhaps you didn't hear. Both Chrome and Firefox will automatically give Comcast's customers Comcast DNS over HTTPS. Mozilla secured a TRR agreement from Comcast in exchange, and presumably Google feels that this agreement plus any undisclosed paperwork from Comcast that they were shown as part of their onboarding process is enough to likewise trust it automatically in Chrome. We expect to see more ISPs doing this over the next few years. If you cannot beat them, join them, eh?