Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ fpoling 3 days ago

That does not work as DNS is insecure. DNSSEC is not there and may never will.

▲ryandv 3 days ago | parent | next [-]

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...

▲avodonosov 3 days ago | parent [-]

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.

▲detaro 3 days ago | parent | prev [-]

And would be replacing the CA PKI with an even more centralized PKI.