Alternatively they can use secondary challenge-response auth which depends on some credentials being deployed to your server. Mitm-ing it wouldn't give the attacker anything interesting in that case.
They can use a secondary challenge, but this being optional completely defeats the purpose. A MITM attack will allow an attacker to pretend to be the target during creation of a new cert, tricking a random CA into giving them a valid cert. You do not need to use the CA that the site owners use, so their use of an extra challenge is irrelevant.
Credit cards literally rely on every single merchant not leaking their info, yet as flawed as that is, there's no great pressure to replace them.
Even if DNS by itself was secure enough to validate, this is a single factor and there are many ways to exploit a single factor. Why a secondary mechanism/factor isn't required for critical infrastructure makes no sense.
Do they actually do that in practice? Are they required to do so? (How many sources and how far distinct?)
Why? It goes over infrastructure that you nor they control.
It might be worth illustrating what happens here, as it's not immediately clear from common DNS settings or common commands. First, the client asks their local DNS server, the one you get via DHCP or configure (for example 8.8.8.8 which is by definition already outside your network, but for argument's sake let's assume that they're smarter than that and they pick one inside their own network). Let's say this one doesn't have it in cache, so then it has to go out and ask the TLD (let's assume it has the TLD cached).
The TLD, for example `.com`, will say "the name servers for your.example.com can be found at ns.your.example.com" and it gives the IP addresses for those. Now the local resolver at the CA has to go and ask there for your domain. In this final step, if nowhere else, it will have to leave any sort of trusted network and venture into whatever place the user's servers are at. This could be anywhere in the world, with all sorts of intermediate networks.
They're able to use many secret locations to perform the query.
There is a theory that it is very unlikely an attacker can detect and get leverage over every network between every one of those secret locations for an indeterminate amount of time, without being discovered.
Alas "No" isn't an option for that public WiFi access point you're using, or most mobile service, or your mom's Internet, the average corporate workplace, and so on. So even though this is hardly foolproof it makes a huge difference.
Yet both the user and DV certificate issuers rely on the same DNS that you consider unreliable. So you seem to dismiss DV certificates altogether but your comment seems to imply that you only want to dismiss certificates as DNS records. There's something very inconsistent about your comment.
While not perfect it’s generally quite true for the majority case.
I don't know if they document it somewhere, but it is essentially trivial for letsencrypt to use a DNSSEC validating resolver.
So that means that if you care about DV security, you enable DNSSEC.
It's interesting, even though the $0 price isn't intended to be the main draw a large number of domains with broken DNS fixed it to get Let's Encrypt working rather than pay a CA that doesn't care...
So if you have DNSSEC you can deny all the CAs you don't trust. If a bad guy leaves the CAA record alone they can't get a cert. If they try to replace the CAA record or deny it exists they fail DNSSEC checks.
If your chosen CA agrees to only use a method that's actually secured you get an actual bona fide panacea, for the very affordable price of deploying DNSSEC and CAA, automating cert issuance and getting your DNS config right.
* First, most CAs don't do DNSSEC today, or, if they do, do DNSSEC fail-open.
* Second, CA's can already do multi-perspective DNS lookup, which means that a practical attack to defeat CAA over standard DNS requires an on-path attacker. But if the attacker is on-path, most of the mechanisms CAs use to validate a domain fail, even if you use DNSSEC.
* Finally, there's already a replacement for all this stuff in progress: RDAP, a secure JSON API that allows data to be pulled directly from registrars. Every mainstream browser and every CA/B forum CA voted to add it to the BRs; it's going to be implemented. If you really believe that something like CAA is the future for DV certs, then it seems pretty obvious that RDAP is going to be the way that happens.
DNSSEC is a dead letter.
Your first point argues from an alleged fact, not in evidence, that "most CAs" don't obey the Baseline Requirements in respect to their requirement to use DNSSEC to avoid an on-path attacker replacing or removing CAA records. Do you have such evidence? As I said, this requirement caused CAs to spit feathers, but that's also true of e.g. record keeping requirements and CAA checking itself. One of the unexpected side benefits of Let's Encrypt at scale is that arguments go like this:
Big CA: This requirement is crazy, we issue a vast number of Web PKI certs, and the requirement would cause us to do X for most of those certs, that's just not technically feasible, the requirement must be removed.
Let's Encrypt: We do X for every single cert we issue. Big CA the logs show you issuing only 4% as many certs as us, are there hundreds of times more than you don't log?
Big CA: Um, er, oh, we just realised our single-threaded PHP program might be a bottleneck, we're investigating upgrading to PHP4 to work around that.
But then your second point argues the reverse, that CAs "can" do multi-perspective, and so even though they mostly don't we should pretend they all do. Then it jumps from this backwards argument to claiming all of the Ten (well, nine now) Blessed Methods are vulnerable to an on-path attacker "even if you use DNSSEC", when in fact several are not.
Try it, write down the Ten Blessed Methods as they stand today (yes there are currently nine), then mark whether an on-path attacker succeeds against this method when DNSSEC is in place
3.2.2.4.3, 3.2.2.4.7 and 3.2.2.4.12 are unaffected by an on-path attacker. 3.2.2.4.3 is out-of-band, which I'm sure won't bother a nation state adversary like the NSA, but is otherwise pretty good, 3.2.2.4.7 is in DNS itself, and so protected by DNSSEC, and 3.2.2.4.12 is a simple database lookup, just one that's only possible if your CA is also your registry/ registrar.
The good thing about Google doing DNSSEC validation that on average zones can either be unsigned or need to have valid signatures.
By signing your own domains with DNSSEC and assuming CAs do DNSSEC validation you can protect your own domains from malicious DV certificates.
That's a nice feature. If you don't like DNSSEC, nobody is forcing you to sign your zones. I can still sign my zones even if you don't sign yours.
The next step would be for CAs to honour DANE records.
I still think there's a better way, though. Surely it must be possible to do some consensus through WebRTC and end up with something that lets me run my own domain-specific CA, at least for DV certs.