This definitely looks interesting, but I'm a bit disappointed this is intended to be solely a CA-side check. I'd much rather specify with DNSSec a set of root CA certificates that are trusted to sign certs for my domain, that the browser could download and trust at the same time it resolves the hostname. Perhaps with the limitation that they must be served (as specified for CAA) via DNSSEC, and potentially by the DNS servers on the glue record. It should be easy to use similar proofs of ownership to LetsEncrypt if that additional level of trust is desired.
LetsEncrypt is awesome, but the rate limiting and some missing features can be a bit of a buzzkill and require extra engineering to work around (e.g. reusing FQDN by reverse proxying on path if you're, say, deploying one environment per pull request). It's a nontrivial of work to make sure all your resources are using relative URLs just so they can be mounted on any path on a reverse proxy.
I'd much rather be able to specify my own Root CA on my DNS server and then just let my Vault intermediate CA generate certs to its little heart's content. No rate limiting, no '*' limitations, etc. And I wouldn't have to ask my users to either accept my invalid cert manually each time (poor security), trust each cert permanently (poor ux), or trust my CA cert for all domains anywhere (a level of trust I'm not sure I'm comfortable with -- back to poor security).
DNSSEC is a PKI, like the CA system, whose roots are de jure controlled by governments, and for which no "CA death penalty" can be imposed by browsers. A bad plan.
I think that would be fairly easy to create rules for, though. Only check at the level where registrars are handing out domains (i.e. trust the most-specific SOA, not counting TLD).
In fact, with LetsEncrypt or DV in general, I'm not sure what exists already to stop the scenario you're referring to. My TLD can decide they want certs for my domain and start advertising their nameservers to any IP addresses owned by LetsEncrypt.
As it is there's plenty of manual checking that keeps CAs in check. I don't see why the same processes couldn't be applied to such a system.
You can check that a new certificate was issued for your domain through Certificate Transparency. Maybe if DANE/TLSA certs would also have be submitted to CT logs and browsers required CT that'd provide stronger security that we have now...
Another thing is DNSSEC's reliance on RSA 1024 (did that change?).
It will take a while until everyone has upgraded, but so far no fast attack on RSA 1024 has been reported...
Even elliptic curve algorithm based keys are possible now (and recommended because of their small size, which is good for one packet UDP answers, which is not possible with RSA 2048)
Other problems with DNSSEC aside, the crazy thing here is the suggestion to replace the Web PKI with a system that has taken longer to migrate towards safe key sizes than the existing solution. 1024-bit keys for end-entity certificates were deprecated in 2013 and the last 1024-bit roots were pulled in 2014-2015 (ish?). I don't feel like the CA/B Forum is a particularly fast-moving body, so this is pretty telling.
You can detect meddling with your DNS easily with appropriate monitoring scripts. Also, what stops governments to fully replace your domain with their own, including valid certs?
Your argument is at best one against DNS, not DANE. This is not how the internet works today. It works because we (thankfully) can choose from a lot of top level domains, with very different threat levels. If one goes rogue, choose another one.
> Also, what stops governments to fully replace your domain with their own, including valid certs?
The threat is doing this but only for a small number of people. That could go unnoticed if they could provision certs in the dns. If a CA issues bad cert you see it in CT logs and the CA gets punished.
It can only go unnoticed if you do not check your DNS and your certs via monitoring. You should absolutely do this, even if it is just to be sure you didn't mess something up by accident.
If a government acting malevolent on a top level domain is detected, alarm bells should ring. Avoid, avoid, avoid. There are enough other TLDs available, with other governments and different threat levels.
If you truly believe this, then DANE on .COM domains is already a nonstarter, because the DOJ has been compromising the "integrity" of the .COM zone (stipulating that it has any "integrity" to begin with) for many years in the service of various public policy objectives.
Which TLD should Google move to, where they'll be safe from this kind of interference? How should they transition? You can't simply redirect from .COM to the new domain.
LetsEncrypt is awesome, but the rate limiting and some missing features can be a bit of a buzzkill and require extra engineering to work around (e.g. reusing FQDN by reverse proxying on path if you're, say, deploying one environment per pull request). It's a nontrivial of work to make sure all your resources are using relative URLs just so they can be mounted on any path on a reverse proxy.
I'd much rather be able to specify my own Root CA on my DNS server and then just let my Vault intermediate CA generate certs to its little heart's content. No rate limiting, no '*' limitations, etc. And I wouldn't have to ask my users to either accept my invalid cert manually each time (poor security), trust each cert permanently (poor ux), or trust my CA cert for all domains anywhere (a level of trust I'm not sure I'm comfortable with -- back to poor security).