[iuafhiuah]

I am glad it looks like the IETF ACME specification only addresses the HTTP-01 challenge. I really would like to see improvements made to the DNS-01 challenge before it's ratified, namely, let us publish a public key to a TXT record and use the private key to sign the renewal request. Then I can revoke certbot's access to my DNS records and stop hacking the `.well-known` path.

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

[phasmantistes]

Sorry, can you clarify what you mean by this? The ACME spec (RFC 8555: https://www.rfc-editor.org/rfc/rfc8555.html) fully specified both the HTTP-01 (Section 8.3) and the DNS-01 (Section 8.4) challenges nearly four years ago. The TLS-ALPN-01 challenge was fully specified in RFC 8737 (https://www.rfc-editor.org/rfc/rfc8737) about a year later.

In addition, the new work mentioned in this letter is ARI, or ACME Renewal Info, which is not directly tied to any of the aforementioned renewal methods.

[rossy]

If your concern is that certbot has access to your DNS records, you can set up a CNAME or NS record on _acme-challenge.your-domain and serve the TXT record from a separate, isolated DNS server.

[iuafhiuah]

That's an interesting solution to mitigating risk. I wasn't aware that LE would follow a CNAME to a different TXT record.

Although it does require an additional NS which is an additional maintenance overhead - that is preferable to leaving automated services sitting around with write access to important domains. At least until I can stop regularly writing DNS records.