First impression: with automation and short lived certificates, the Certifying Authorities become similar to Identity Providers / OpenID Provider in openid / openid-connect. The certificates are tokens.
And significant part of security is concentrated around the way Certifying Authorities validate the domain ownership. (So called challenges).
Next, maybe clients can run those challenges directly, instead of relying onto certificates? For example, when connecting a server, client client sends two unique values, and the server must create DNS record <unique-val-1>.server.com with record value of the <unique-val-2>. Client check that such record is created and thus the server has proven it controls the domain name.
Auth through DNS, that's what it is. We will just need to speed up the DNS system.
This will not work as any attacker that can MITM the client (likely scenario for end-users), can also MITM this "certificate issuing" setup and issue their own cert.
The reason an attacker can't MITM Let's Encrypt (or similar ACME issuers) is because they request the challenge-response from multiple locations, making sure a simple MITM against them doesn't work.
A fully DNS based "certificate setup" already exists: DANE, but that requires DNSSEC, which isn't wildly used.
You are right that the scheme I described is vulnerable. Even without MITM. Just fakeserver.com upon receiving request from client sends equal request to server.com, which creates the needed DNS record and thus real client is "convinced" that fakeserver.com controls DNS.
But that just a nuance that could be fixed. I elaborate little more on what I mean in https://news.ycombinator.com/item?id=43712754
Thx for pointing to DANE.
That does not work as DNS is insecure. DNSSEC is not there and may never will.
But this is already basically how Let's Encrypt challenges certificate applicants over ACME DNS01 [0].
I would be more concerned about the number of certificates that would need to be issued and maintained over their lifecycle - which now scales with the number of unique clients challenging your server (or maybe I misunderstand, and maybe there aren't even certificates any more in this scheme).
Not to mention the difficulties of assuring reasonable DNS response times and fresh, up-to-date results when querying a global eventually consistent database with multiple levels of caching...
[0] https://letsencrypt.org/docs/challenge-types/#dns-01-challen...
In the scheme I descrubed where client directly runs challenges the certificates are not issued at all.
I am not saying this scheme is really practical currently.
That's just an imaginary situation coming to mind, illustrating the increased importance of domain ownership validation procedures used by Certifying Authorities. Essentially the security now comes down to the domain ownership validation.
Also a correction. The server not simply puts <unique-val-2>, it puts sha256(<unique-val-2> || '.' || <fingerprint of the public key of the account>).
Yes, the ACME protocol uses some account keys. Private key signs a requests for new cert, and public key fingerprint during domain ownership validation confirms that the challenge response was intended for that specific account.
I am not suggesting ACME can be trivially broken.
I just realized that risks of TLS certs breaking is not just risk of public key crypto being broken, but also includes the risks of domain ownership validation protocols.