Certficate transparency helps to mitigate that by creating a public audit log of certificate issuance.
An attack against the global public DNSSEC would be much harder to mount undetected, as it is logged and cached by nature of its design.
It's not one of my best arguments against DNSSEC, but it is a valid one: the fact that the people designing and advocating for it don't appear to understand the Internet threat model.
DNSSEC did make one important design decision: Signing is offline. That alone makes the threat model different than with TLS, and makes for some interesting use cases.
I don't know how pure offline signing would have made anything better for DNSSEC (I think it makes a lot of things about it worse), but let's at least be clear that the offline signing design failed.
You didn't really address what I said. My argument, which I think is pretty straightforward, is that it is not in fact harder to carry out pinpoint attacks on DNSSEC than it is to do so on TLS. In fact: it's easier; in many ways, modern browsers act as hundreds of millions of sensors in a distributed CA surveillance system, one that has gotten multiple CAs killed. No DNS software works that way.
Are we talking about the public CA system or TLS in general? The former should be fairly obvious that it is useless in the hards of end users, as Google even had to hard code policy for their own services in their client. The latter argument would depend on what type of attack we're discussing. A wide public attack where you have "hundreds of millions" of clients affected would be impractical to keep undetected in any system. Manipulating a single connection with stolen keys is likely to stay undetected in any case, but where having the information cached at least is a possibility.
Somehow, you claimed, DNSSEC's offline signing design had something to do with how hard it was to conduct pinpoint attacks against DNSSEC.
No, that's not true.
But also: DNSSEC isn't an offline-signing system anymore: the BCP mode of deployment requires online signing; otherwise, dumping all the hosts in a zone is about as hard as cracking a 1990s password file.
You've seen zones where not even that level of protection is employed. Ok? What does that have to do with whether it's easy to launch pinpoint attacks against DNSSEC?
Oh, but pinpoint attacks are possible against TLS. Yes? And? The premise of this subthread is your (false) claim that it's not straightforward to do that against DNSSEC too.
Again: not only is it straightforward to do that, but it's actually easier, because, once again, no end-user DNS resolver also functions as security telemetry surveilling the DNS PKI, unlike the Web PKI where that is in fact the case.
I pointed out that the design for offline signing makes for interesting use cases. You now claim that every real world deployment is online signed, which is not my experience. At least you acknowledge real world deployments.
That has nothing to do with the complexity of pinpointing a connection to break, and nowhere did I make the claim that any attacks are straightforward. I did make the point that it is not easier and that it may very well be more complex. Pinpointing a TLS stream and inserting a false certificate is trivial if you posess a valid CA key, pinpointing the DNS query corresponding to a specific TLS stream is an added complexity (especially where multiple resolvers can be involved, where you also run the risk of being stuck in a cache).
I'm not sure what kind of TLS stack ever delivered telemetry on valid signatures post facto, unless you refer to web browsers on the public Internet which is a different question entirely.
1) Anyone can submit a certificate to the CT logs
2) It will become mandatory that certificates are logged for Chrome to trust them in a matter of weeks (other browsers will follow): https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...