[Ayesh]

I'm surprised the ballot passed, unanimously even! I get that storing the DNS credentials in the certificate renewal pipeline is risky, but many DNS providers have granular API access controls, so it is already possible to limit the surface area in case the keys get leaked. Plus, you can revoke the keys easily.

The ACME account credentials are also accessible by the same renewal pipelines that has the DNS API credentials, so this does not provide any new isolation.

~It's also not quite clear how to revoke this challenge, and how domain expiration deal with this. The DNS record contents should have been at least the HMAC of the account key, the FQDN, and something that will invalidate if the domain is transferred somewhere else. The leaf DNSSEC key would have been perfect, but DNSSEC key rotation is also quite broken, so it wouldn't play nice.~

Is there a way to limit the challenge types with CAA records? You can limit it by an account number, and I believe that is the most tight control you have so far.

---

Edit: thanks to the replies to this comment, I learned that this would provide invalidation simply by removing the DNS record, and that the DNS records are checked at renewal time with a much shorter validation TTL.

[amluto]

> but many DNS providers have granular API access controls

And many providers don't. (Even big ones that are supposedly competent like Cloudflare.)

And basically everyone who uses granular API keys are storing a cleartext key, which is no better and possibly worse than storing a credential for an ACME account.

[agwa]

> It's also not quite clear how to revoke this challenge, and how domain expiration deal with this

CAs can cache the record lookup for no longer than 10 days. After 10 days, they have to check it again. If the record is gone, which would be expected if the domain has expired or been transferred, then the authorization is no longer valid.

(I would have preferred a much shorter limit, like 8 hours, but 10 days is a lot better than the current 398 day limit for the original ACME DNS validation method.)

[mcpherrinm]

We (Let’s Encrypt) also agree 10 days seems too long, so we are migrating to 7 hours, aligning with the restrictions on CAA records.

[mcpherrinm]

Yes, you can limit both challenge types and account URIs in CAA records.

To revoke the record, delete it from DNS. Let’s Encrypt queries authoritative nameservers with caches capped at 1 minute. Authorizations that have succeeded will soon be capped at 7 hours, though that’s independent of this challenge.

[UltraSane]

I use AWS Route53 and you can get incredibly granular with API permissions

Key condition keys for this purpose include:

    route53:ChangeResourceRecordSetsActions: Limits actions to CREATE, UPDATE, or DELETE.

    route53:ChangeResourceRecordSetsRecordTypes: Limits actions to specific DNS record types (e.g., A, CNAME, TXT).

    route53:ChangeResourceRecordSetsRecordValues: Limits actions based on the specific value of the DNS record.

    route53:ChangeResourceRecordSetsResourceRecords: For more complex scenarios, this can be used to control access based on the full record set details.

[mcpherrinm]

This wasn’t the first version of the ballot, so there was substantial work to get consensus on a ballot before the vote.

CAs were already doing something like this (CNAME to a dns server controlled by the CA), so there was interest from everyone involved to standardize and decide on what the rules should be.