What on earth are you talking about? There is no concept of "issuing" anything in DNSsec/DANE. And why are you assuming DNS is frozen in its current state while the Web PKI can be ratcheted down? (And also, I'm not arguing for a "DANE-first" world. I'm arguing for a "DANE-and" world.)
What Verisign can do in all of this is change the NS and DS for a given domain, and Mallory can run different DNS servers for that domain then, giving out different data, including TLSA records. If they do this, they can also get ACME certs, except that will result in a permanent CT entry. Great feature! We should build a clone for DNSsec.
Will the owner of the domain notice either of these things? Hard to say. In both cases, you need to query something (CT logs or DNS caches) for your own domain, and check if things pop up you didn't put there. You can't query specific ISP's caches, that sucks. And it's only visible in DNS while under attack. Still, my gut feeling is more people will actually notice their NS getting messed with, because it happens by accident when they screw up their DNS. "credit card expired" and stuff like that. DS records are automatically monitored by any self-respecting DNSsec implementation for propagation & state triggering, but only for a given list of servers & caches. The attack could probably stay under the radar by keeping 1.1.1.1 and 8.8.8.8 intact, or at least some instances of it.
And then there's that tiny problem that only browsers really care about CT. Anything else is, at best, protected only if it can't be distinguished by fingerprint on TLS connect. DNS can only be subverted on a per-resolver/cache basis. Not really better, not worse, but different.
I have two takeaways from this. First, I should poke some people at IETF about inventing "DT", DNSsec Transparency. I expect it could probably be implemented in the DNS caches [in addition to end resolvers]. That'd be an interesting way of rolling things out: you can cover shitty client devices without changing them at all. If they use a DNS cache doing "DT", they'd be covered, even if not perfectly. The best time to do any of this would've been 2013, when CT came along. The second best time is now.
The other takeaway is, I should probably prod ENISA people to see if the EU bureaucracy can force some things. We've recently started working with them (mostly because the US apparatus is underfunded to hell and can't answer an e-mail with less than 6 months of delay), though we're only a tiny cog. And if the thought of the EU requiring some level of DNSsec or "DANE-and" gives somebody a heart attack: good!
And let's at least not lie about one thing: if "DANE-and" is being validated for a given target, that does prevent exploiting the eMudhra compromise.
P.S.: before we get in another pile of miscommunication: DNSsec/DANE validation goes on the end application or end host DNS component and the cache. The AD bit is a misdesign and scourge on DNSsec, should be ignored on any network packet, and is not what you build trust on. (AFAIK this is consensus in the DNS world, and one of the things getting ratcheted on their side.)
What Verisign can do in all of this is change the NS and DS for a given domain, and Mallory can run different DNS servers for that domain then, giving out different data, including TLSA records. If they do this, they can also get ACME certs, except that will result in a permanent CT entry. Great feature! We should build a clone for DNSsec.
Will the owner of the domain notice either of these things? Hard to say. In both cases, you need to query something (CT logs or DNS caches) for your own domain, and check if things pop up you didn't put there. You can't query specific ISP's caches, that sucks. And it's only visible in DNS while under attack. Still, my gut feeling is more people will actually notice their NS getting messed with, because it happens by accident when they screw up their DNS. "credit card expired" and stuff like that. DS records are automatically monitored by any self-respecting DNSsec implementation for propagation & state triggering, but only for a given list of servers & caches. The attack could probably stay under the radar by keeping 1.1.1.1 and 8.8.8.8 intact, or at least some instances of it.
And then there's that tiny problem that only browsers really care about CT. Anything else is, at best, protected only if it can't be distinguished by fingerprint on TLS connect. DNS can only be subverted on a per-resolver/cache basis. Not really better, not worse, but different.
I have two takeaways from this. First, I should poke some people at IETF about inventing "DT", DNSsec Transparency. I expect it could probably be implemented in the DNS caches [in addition to end resolvers]. That'd be an interesting way of rolling things out: you can cover shitty client devices without changing them at all. If they use a DNS cache doing "DT", they'd be covered, even if not perfectly. The best time to do any of this would've been 2013, when CT came along. The second best time is now.
The other takeaway is, I should probably prod ENISA people to see if the EU bureaucracy can force some things. We've recently started working with them (mostly because the US apparatus is underfunded to hell and can't answer an e-mail with less than 6 months of delay), though we're only a tiny cog. And if the thought of the EU requiring some level of DNSsec or "DANE-and" gives somebody a heart attack: good!
And let's at least not lie about one thing: if "DANE-and" is being validated for a given target, that does prevent exploiting the eMudhra compromise.
P.S.: before we get in another pile of miscommunication: DNSsec/DANE validation goes on the end application or end host DNS component and the cache. The AD bit is a misdesign and scourge on DNSsec, should be ignored on any network packet, and is not what you build trust on. (AFAIK this is consensus in the DNS world, and one of the things getting ratcheted on their side.)