[rainsford]

I'll admit I haven't spent a ton of time thinking through all the implications, but that proposal seems like it comes with some significant security tradeoffs. In particular, you'd lose the ability to prove you control the domain name at the time of certificate renewal. Instead, the key pair approach shows you controlled the DNS records for the domain at some point and your entry has yet to be deleted. From the certificate issuing standpoint, that seems like a much weaker security guarantee. Certbot's access to your DNS records does mean you have to protect those credentials, but the overall requirement seems like a feature rather than a bug.

[iuafhiuah]

I don't see announcing a public key being much different to PGP or other trust systems. If I say I sign my messages with `63847B4B83930F0C` and you save that information you'll continue to trust that it's me in the future even though there is no proof I still control the private key.

If anything, as far as I'm concerned, DNS-based challenges are a stronger proof that I own the domain as it requires access to the nameserver. HTTP-based challenges just prove that I have access to a computer pointed to by a DNS record which is far easier to get wrong. This is why wildcard domains cannot be issued to HTTP challenges, just because I can serve a file on a subdomain doesn't mean I own the parent domain.

But I agree, using a key-based DNS challenge would be a new feature. It was discussed before but at the time LE devs didn't come to a consensus with how to move it forwards.

[comex]

To be fair, “you controlled the DNS records for the domain at some point and your entry has yet to be deleted” could also describe the HTTP-01 challenge. Admittedly, having the A/AAAA record point to the wrong place is much more likely to be noticed than having a stray TXT record lying around. Perhaps more worrying is the possibility of having a keypair that is legitimately being used to sign certificate requests, but which an attacker also stole a copy of at some point. (Assume that the server owner doesn’t know they were compromised and hence didn’t rotate the key, but the attacker subsequently lost access for some reason.) Such an attacker would likely have also stolen the TLS private key, but that only stays valid for 90 days, whereas for this keypair approach to be useful, the keypair would have to stay valid for a long time or indefinitely…

[kelnos]

Does it? Under the approach of storing a public key in DNS, certs can be issued long after the person asking for one has lost access to the website, if the pubkey record hasn't been deleted.

With http-01, ownership has to be proven every time a new cert is issued.

> Such an attacker would likely have also stolen the TLS private key, but that only stays valid for 90 days

That doesn't have to be the case; the private key can be valid for as long as someone wants it to be, unrelated to the validation period of the cert that is issued. Yes, it does look like certbot generates a new keypair for every renewal, but in a world where we were putting a pubkey in a DNS record, the private key would certainly have a much longer validity, as otherwise there'd be no point to doing it this way in the first place.