5 ms·

If Mozilla cared about preventing DNS tampering, they could have done DNSSEC 10 years ago. That would have totally killed ads, ISP typosquatting, and captive po

If Mozilla cared about preventing DNS tampering, they could have done DNSSEC 10 years ago. That would have totally killed ads, ISP typosquatting, and captive portals. They, like all browsers, rejected that source of end-to-end security. The fact is that they want to enable DNS tampering, because they want to use it as a way of enforcing their idea of "safety". So they're building this giant, highly centralized, and easily pressured, infrastructure of "trusted resolvers" that can mess with your DNS results to their heart's content. This will, of course, be a huge attractant for bad actors who want to do things even more harmful than injecting obnoxious advertizing. As for privacy, the only way that can work, even with something like DNSCrypt, is if the individual user chooses the resolver from among a very large set of possibilities.. which Mozilla is not enabling. Either that, or relatively exotic anonymization stuff that's not actually worked out, and that Mozilla has shown zero interest in working out. "Trusted resolvers" just move the privacy problem to a different place, and, again, it's a highly centralized place that's easy to subvert. And DNS-over-TCP is desirable for sure, but it does nothing about tampering or privacy. It's just irrelevant, except maybe as a preliminary step making it easier to deploy some of the stuff that might actually help.

kadoban 5y ago
How could Mozilla have "done" DNSSEC 10 years ago? Isn't that pretty much just not in their control?
- Hizonner 5y ago
  If TLDs are signed (which they have been for a long time), and if the browser checks DNSSEC, you can't typosquat, because you can't spoof the TLD server's signature on the typo. That requires no cooperation from anybody but the browser and the TLD. WIth DNSSEC enabled, somebody can still impersonate an unsigned domain, but the whole reason that there are so many unsigned zones to begin with is that nothing checks the signatures, so there's no incentive to sign. By actually doing the checks, browsers, including Firefox, could have created an incentive for widespread DNSSEC signing. So they could have both unilaterally gotten a lot of benefit for their users, and encouraged wider DNSSEC deployment that would have produced further benefit. Add in DANE, and it would also have given a much more satisfying fix for a bunch of CA issues that they've chosen to band-aid with stuff that only half works. You could probably even have gotten to a world with zero-cost TLS certs well before enough pressure built up to make Lets Encrypt come along.
  - kadoban 5y ago
    Interesting, thank you. That does sound more satisfying as a fix (though also sounds harder and possibly riskier. If they're the only ones checking, will some sites be broken only in Firefox?)
  - tptacek 5y ago
    You're saying it's one way, but it's the opposite way. Huge portions of the Internet's user base resolves through servers that will validate DNSSEC if it's available. Still, nobody --- most especially not organizations with serious security teams --- signs their domains. That's not because they don't care about security. It's because DNSSEC makes sites unreliable, and the failure mode for DNSSEC is just about the worst possible mode: your site simply vanishes from the Internet, as if it hadn't existed at all. None of this is hypothetical. It happened, for instance, at the launch of HBO NOW, when a screwed up DNSSEC record made the site vanish for everyone resolving through Comcast, which pointlessly verifies DNSSEC.
    - Hizonner 5y ago
      DNS without DNSSEC will also "make your site vanish" if you administer it incompetently. And that's not hypothetical either; it happens all the time. As for the "servers that will validate DNSSEC if it's available", the operators of the servers that "huge portions of the Internet's user base" use are exactly the people who are potential threat actors in most DNS tampering scenarios. That's not useful or effective validation. It makes no sense to put the choice of whether to validate in their hands, and obviously nobody can trust their validation.
  - SilverRed 5y ago
    DNSSEC does not protect privacy which is more important than integrity since TLS already does that. Even worse, making DNSSEC well used might have pushed privacy protocols out of priority as people claim DNS is good enough already.
tialaramex 5y ago
One of the reasons Mozilla couldn't "do" DNSSEC 10 years ago over plaintext DNS is that for some (enough) clients this doesn't work. Their DNS is broken, it was always broken, but so long as you only ever ask something easy like "news.ycombinator.com A?" it worked well enough. Asking DNSSEC queries doesn't work. "Last Change Broke It" rules apply so Mozilla gets the blame. With DoH of course this is much less relevant. The people operating Trusted Resolvers for DoH are obliged to actually implement the protocol correctly. If you choose a DoH provider which does DNSSEC for you (such as Cloudflare's 1.1.1.1), and you trust that provider, your answers are DNSSEC validated, today, without any changes to Firefox. Millions of people benefit, zero work. If you're concerned that Trusted Resolvers aren't enough privacy, Oblivious DoH eventually means that the TRs don't see your query any more, so the people answering the query don't know who you are, and people who know who you are don't know what your query is.
- Hizonner 5y ago
  I'll bet a comparable number of clients won't be able to reach DoH servers for one reason or another. Especially because there seem to be people who are going to actively try to block them. Whenever you change anything, something will break. And it would have been relatively easy to put up a notice that said "your DNS server seems to be dropping all EDNS0 data or whatever stupid thing it's doing; would you like to switch servers"? Which would have avoided centralizing everybody by default. I know there were enterprise firewalls that broke DNSSEC on any packet that went through them... but frankly the sellers of those firewalls deserved to get heat, and any enterprise that would deploy that kind of broken crap isn't an organization I'd want to support as user. And that still doesn't justify putting DNS on top of HTTP of all things. But that's another story. As for Cloudflare doing DNSSEC checks, the fact that I shouldn't be trusting Cloudflare to do the validation for me is kind of the point. Validation (final validation, at least) belongs in the endpoint. If "oblivious DoH" is what it sounds like, it sounds like maybe I have to retract "zero interest in exotic anonymity". Which I am very happy to have to do.
  - tptacek 5y ago
    DNSSEC has never validated at the endpoints. By design, validation occurs --- has to occur --- at the recursive server. The channel between you and your recursor is "secured" with a single bit, which says "yeah, sure, I did DNSSEC validation". Don't blame the systems software for this; it's a terrible protocol.
josephcsible 5y ago
> If Mozilla cared about preventing DNS tampering, they could have done DNSSEC 10 years ago. DNSSEC only protects integrity, not confidentiality or availability. It still lets evil ISPs build a profile of every domain you've ever resolved, and to block your access to certain domains by just dropping your DNS request packets for them. Basically the only thing it stops is them sending you to a fake page (e.g., a pretty block message rather than a generic browser error).
- SilverRed 5y ago
  Also no one cares about integrity since it is already validated by TLS. And it seems that DNSSEC is not even widely supported by TLDs. My domain says DNSSEC is not available. Seems like DNSSEC is another failed spec like certificate pinning.
  - josephcsible 5y ago
    We need DNSSEC for eSNI/ECH to be possible.
    - tptacek 5y ago
      The eSNI drafts I read say explicitly that DNSSEC is not required (there's a whole section about it), which is good, because if it were, eSNI would be dead in the water.
      - josephcsible 5y ago
        I looked again and you're correct. For other readers, the justification is basically that if an attacker can MITM DNS, then they can find out what domains you're going to even without compromising eSNI/ECH.
        tptacek 5y ago
        I double checked the RFCs, but I'm not kidding that you can generally work this stuff out axiomatically (for a change) --- if an important new standard requires DNSSEC, it's not an important new standard, because it can't happen. DNSSEC is moribund.

kadoban 5y ago

How could Mozilla have "done" DNSSEC 10 years ago? Isn't that pretty much just not in their control?

Hizonner 5y ago
If TLDs are signed (which they have been for a long time), and if the browser checks DNSSEC, you can't typosquat, because you can't spoof the TLD server's signature on the typo. That requires no cooperation from anybody but the browser and the TLD. WIth DNSSEC enabled, somebody can still impersonate an unsigned domain, but the whole reason that there are so many unsigned zones to begin with is that nothing checks the signatures, so there's no incentive to sign. By actually doing the checks, browsers, including Firefox, could have created an incentive for widespread DNSSEC signing. So they could have both unilaterally gotten a lot of benefit for their users, and encouraged wider DNSSEC deployment that would have produced further benefit. Add in DANE, and it would also have given a much more satisfying fix for a bunch of CA issues that they've chosen to band-aid with stuff that only half works. You could probably even have gotten to a world with zero-cost TLS certs well before enough pressure built up to make Lets Encrypt come along.
- kadoban 5y ago
  Interesting, thank you. That does sound more satisfying as a fix (though also sounds harder and possibly riskier. If they're the only ones checking, will some sites be broken only in Firefox?)
- tptacek 5y ago
  You're saying it's one way, but it's the opposite way. Huge portions of the Internet's user base resolves through servers that will validate DNSSEC if it's available. Still, nobody --- most especially not organizations with serious security teams --- signs their domains. That's not because they don't care about security. It's because DNSSEC makes sites unreliable, and the failure mode for DNSSEC is just about the worst possible mode: your site simply vanishes from the Internet, as if it hadn't existed at all. None of this is hypothetical. It happened, for instance, at the launch of HBO NOW, when a screwed up DNSSEC record made the site vanish for everyone resolving through Comcast, which pointlessly verifies DNSSEC.
  - Hizonner 5y ago
    DNS without DNSSEC will also "make your site vanish" if you administer it incompetently. And that's not hypothetical either; it happens all the time. As for the "servers that will validate DNSSEC if it's available", the operators of the servers that "huge portions of the Internet's user base" use are exactly the people who are potential threat actors in most DNS tampering scenarios. That's not useful or effective validation. It makes no sense to put the choice of whether to validate in their hands, and obviously nobody can trust their validation.
- SilverRed 5y ago
  DNSSEC does not protect privacy which is more important than integrity since TLS already does that. Even worse, making DNSSEC well used might have pushed privacy protocols out of priority as people claim DNS is good enough already.

tialaramex 5y ago

One of the reasons Mozilla couldn't "do" DNSSEC 10 years ago over plaintext DNS is that for some (enough) clients this doesn't work. Their DNS is broken, it was always broken, but so long as you only ever ask something easy like "news.ycombinator.com A?" it worked well enough. Asking DNSSEC queries doesn't work. "Last Change Broke It" rules apply so Mozilla gets the blame. With DoH of course this is much less relevant. The people operating Trusted Resolvers for DoH are obliged to actually implement the protocol correctly. If you choose a DoH provider which does DNSSEC for you (such as Cloudflare's 1.1.1.1), and you trust that provider, your answers are DNSSEC validated, today, without any changes to Firefox. Millions of people benefit, zero work. If you're concerned that Trusted Resolvers aren't enough privacy, Oblivious DoH eventually means that the TRs don't see your query any more, so the people answering the query don't know who you are, and people who know who you are don't know what your query is.

Hizonner 5y ago
I'll bet a comparable number of clients won't be able to reach DoH servers for one reason or another. Especially because there seem to be people who are going to actively try to block them. Whenever you change anything, something will break. And it would have been relatively easy to put up a notice that said "your DNS server seems to be dropping all EDNS0 data or whatever stupid thing it's doing; would you like to switch servers"? Which would have avoided centralizing everybody by default. I know there were enterprise firewalls that broke DNSSEC on any packet that went through them... but frankly the sellers of those firewalls deserved to get heat, and any enterprise that would deploy that kind of broken crap isn't an organization I'd want to support as user. And that still doesn't justify putting DNS on top of HTTP of all things. But that's another story. As for Cloudflare doing DNSSEC checks, the fact that I shouldn't be trusting Cloudflare to do the validation for me is kind of the point. Validation (final validation, at least) belongs in the endpoint. If "oblivious DoH" is what it sounds like, it sounds like maybe I have to retract "zero interest in exotic anonymity". Which I am very happy to have to do.
- tptacek 5y ago
  DNSSEC has never validated at the endpoints. By design, validation occurs --- has to occur --- at the recursive server. The channel between you and your recursor is "secured" with a single bit, which says "yeah, sure, I did DNSSEC validation". Don't blame the systems software for this; it's a terrible protocol.

josephcsible 5y ago

> If Mozilla cared about preventing DNS tampering, they could have done DNSSEC 10 years ago. DNSSEC only protects integrity, not confidentiality or availability. It still lets evil ISPs build a profile of every domain you've ever resolved, and to block your access to certain domains by just dropping your DNS request packets for them. Basically the only thing it stops is them sending you to a fake page (e.g., a pretty block message rather than a generic browser error).

SilverRed 5y ago
Also no one cares about integrity since it is already validated by TLS. And it seems that DNSSEC is not even widely supported by TLDs. My domain says DNSSEC is not available. Seems like DNSSEC is another failed spec like certificate pinning.
- josephcsible 5y ago
  We need DNSSEC for eSNI/ECH to be possible.
  - tptacek 5y ago
    The eSNI drafts I read say explicitly that DNSSEC is not required (there's a whole section about it), which is good, because if it were, eSNI would be dead in the water.
    - josephcsible 5y ago
      I looked again and you're correct. For other readers, the justification is basically that if an attacker can MITM DNS, then they can find out what domains you're going to even without compromising eSNI/ECH.
      - tptacek 5y ago
        I double checked the RFCs, but I'm not kidding that you can generally work this stuff out axiomatically (for a change) --- if an important new standard requires DNSSEC, it's not an important new standard, because it can't happen. DNSSEC is moribund.