[some_bird]

We could also just get rid of webPKI entirely?

But you still need a public key for TLS? Well, just put it in DNS!

And assuming your DNS responses are validated by DNSSEC, it would be even more secure too. You'd be closing a whole lot of attack vectors: from IP hijacks and server-side AitM to CA compromises. In fact, you would no longer need to use CA's in the first place. The chain of trust goes directly from your registrar to your webserver with no third party in between anymore. (And if your registrar or webserver is hacked, you'd have bigger problems...)

[bwesterb]

The biggest blocker for DANE at the moment is that it doesn't have a transparency story. There is no good visibility into whether your TLD advertises a second pair of zone signing keys to few you don't control. We can add some transparency logs as with CT, but then we have a rate-limiting problem. You could have a mix of heavily rate-limited free DNSSEC logs and some paid DNSSEC logs. This is starting to look a lot like the current WebPKI then. I must say that this is an under explored area.

[some_bird]

But you don't need the transparency! The whole transparency thing was added because we have hundreds of Certificate Authorities all over the world who would otherwise have the power to secretly sign a cert for your website without anyone ever knowing.

And if you DO need the extra monitoring, all it takes is periodically retrieving the DNS record and send an alert if it changes. (There is no certificate that needs periodical rotation, you only need to renew the keypair if the server is compromised.)

[tptacek]

That's a serious blocker, but the biggest blocker for it is that it can't reliably be deployed; too much of the Internet is on links that won't pass the records required to verify DANE, which means that browsers need fallback paths for DANE, which means DANE expands, rather than contracts, the threat surface area of the WebPKI.