[wizeman]

> All DNSSEC gives you is a false sense of security as you merrily validate signatures on spoofed records because they're generated by the same people who own the DS record responses.

As opposed to the current system, which also gives you a false sense of security while being vulnerable to exactly the same .COM attack, but also to even more types of attacks?

[growse]

DNS (without DNSSEC) doesn't claim to be secure.

[wizeman]

First of all that doesn't matter, because people trust what DNS does regardless of whether it claims to be secure or not. I've never seen anyone or any software distrust a DNS response unless they already know what it was supposed to be. The only exception I know of is Let's Encrypt, which does check DNS responses from multiple sites around the world to verify that they're the same, something which isn't really a security guarantee, it's just a heuristic. And which practically nobody else does and which normal users aren't capable of doing.

Furthermore, what we build on top of DNS and which is supposed to protect from DNS attacks and does claim to be secure, like the CA PKI system, actually depends on DNS to be secure (which it isn't) in order to obtain the certificates. Not to mention the CA PKI system also depends on all certificates authorities in the entire world to be well-behaved.

[tptacek]

Stipulate that you can spoof, for any non-LetsEncrypt CA in the world, any DNS response you want. Pick any CA in the Mozilla trust store that you choose. Spoof a response to verify a MAIL.GOOGLE.COM certificate. What do you think happens next?

[wizeman]

What would happen next is that the attacker would succeed in getting his certificate for mail.google.com signed by the CA (remember, there are certificate authorities including Let's Encrypt that sign certificates based on DNS responses alone, but selectively spoofing the A record for the HTTP server would also work).

Presumably the CA would have to have published an entry to the CT log for this certificate. This would allow browsers to verify that the certificate generated by the attacker can be trusted and therefore it could be used by the attacker to perform a man-in-the-middle attack on the Gmail interface against any user in the entire world, without anyone noticing it during the attack.

Some time after the attack has already occurred, Google or someone else would presumably notice that the certificate wasn't actually created by Google, even though everything was correctly published in the CT logs like it was expected for any other normal certificate (I'm being very generous here, multiple companies don't even notice their domains are about to expire until it's too late, including Microsoft).

At this point, it would be expected for browser vendors like Mozilla and Google to distrust this CA because they would assume the CA generated a certificate for a Google domain fraudulently. However, the CA wasn't actually the perpetrator of the attack but it also couldn't prove that it wasn't, and since the browsers don't trust them anymore, the innocent company would be ruined and all their employees would be fired and become miserable.

Meanwhile, hundreds of millions or possibly billions of devices (like Android smartphones) who don't update their system software for months or years (or even never) would still have the now-bankrupt CA in their certificate root stores for a very long time (remember, not all certificate root stores are managed by browsers, some are installed at the OS level), so the attacker could still keep attacking these devices, almost indefinitely, without any issue (especially if he repeats the attack, which he can do indefinitely, ruining many CAs until he somehow got caught).

This is all assuming we're talking about a certificate for an HTTPS server, which is the best case scenario.

If we're talking about a certificate for an SMTP server or a DNS server then the problem is even worse, not in this exact scenario, but in the scenario where one of the many certificate authorities behaves maliciously and generates a fraudulent certificate itself (signing it) but doesn't publish an entry to a CT log, so the attack would never be noticed because SMTP servers and DNS servers don't check SCTs.