Hacker News new | past | comments | ask | show | jobs | submit login

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: