Extended discuss of ACME DNS Labeled With ACME Account ID Challenge

[Xiaohui Lam]

Hi all,

I came across Cloudflare’s blog (https://blog.cloudflare.com/zh-cn/introducing-dcv-delegation), which mentions an RFC draft Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge. This draft proposes a new domain control verification (DCV) method using following DNS record:
_acme-challenge_ujmmovf2vn55tgye.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI"

Key concern of mine revolves around how the validation domain name is constructed by prepending the label:
"_acme-challenge" || base32(SHA-256(Account Resource URL)[0:9])
The verification DNS host _acme-challenge_[suffix]'s suffix is generated from the ACME account URI (account resource URL). However, wouldn’t it be more logical to generate this host from the account public key instead?

Let’s contextualize this with Cloudflare’s use case: they aim to allow users to delegate _acme-challenge_[suffix] via CNAME records. If we use the account URI to generate the DNS host suffix, and Cloudflare users need to enroll certificates from two CAs - such as

  - Let’s Encrypt, and
  - Google Trust Service

Cloudflare will give two CNAME records, e. g:

 - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME "example.org.googletrustservice.acme-delegate.cloudflare.com", for Let's Encrypt
 - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME "example.org.letsencrypt.acme-delegate.cloudflare.com", for Google Trust Service

They would have to create two separate CNAME records (due to different DNS hosts and values for every CA).

In contrast, if the DNS host suffix is generated from the account public key, Cloudflare users would only need to create one CNAME record for delegation. This streamlines the process, enhanced security(publickey is far secure than an url string) and reduces configuration overhead for users.

Thoughts?

[Xiaohui Lam]

It should be following:

 - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME "example.org.googletrustservice.acme-delegate.cloudflare.com", for Google Trust Service
 - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME "example.org.letsencrypt.acme-delegate.cloudflare.com", for Let's Encrypt

Sorry for my typo

[Amir Omidi]

Hi!

However, wouldn’t it be more logical to generate this host from the account public key instead?

If we think about the entire lifecycle of the ACME account, using the public key makes less sense. The workflow that I’ve imagined for this is as follows:

1. Large provider creates ACME accounts on ACME enabled CAs.

2. Large provider ensures that the CA’s have rate limits in place to allow them to do large number of issuances.

3. Large provider communicates these stable strings to the customer to set as CNAME records for DCV delegation.

Now, if we use the public key, these are no longer stable URLs. We effectively have a long lived key, where replacing that key ends up requiring every single customer to change their CNAME records.

With the design that is currently in place, we can use https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.5 to rollover the account keys, without causing disruptions to the end users.

Hope this answers the inquiry!

-- 
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c8a84911-53fa-418f-b742-9109157c1997n%40mozilla.org.

[Xiaohui Lam]

Hi Amir,

Thank you for your response, specially posted here, your concern when drafting the RFC.

Based on my experience, instances of ACME account key compromise are extremely rare. I also have full confidence in Cloudflare’s robust security operations capability - such account key compromises are highly unlikely to occur internally at Cloudflare.

My suggestion is to draft the document to retain both the current account URI-generated suffix and add an account key-generated suffix. This would allow delegate operators (such as Cloudflare) to implement the optimal approach for their customers.

Thank you.

[Amir Omidi]

> Based on my experience, instances of ACME account key compromise are extremely rare. I also have full confidence in Cloudflare’s robust security operations capability - such account key compromises are highly unlikely to occur internally at Cloudflare.

I don't doubt this, but most of what we do in this space is planning for worst case scenarios. As ACME is meant to facilitate short-lived credentials, I don't think it would be responsible to build features that rely on long (forever?) lived keys.

Furthermore, the issue isn't only key compromise. There are many circumstances why this key might change. For example:

1. Regulatory requirements on not having long-lived keys.

2. There being a runtime problem during generation of this ACME account key that is discovered in the future.

3. Moving away from ECC/RSA keys in the future.

I feel very strongly that we should not be building a feature that takes a strong dependency on the life of a key, where it doesn't really need to.

Thanks!

[Xiaohui Lam]

Hi Amir,

Thank you for post expanding contents.

> I don't doubt this, but most of what we do in this space is planning for worst case scenarios. As ACME is meant to facilitate short-lived credentials, I don't think it would be responsible to build features that rely on long (forever?) lived keys.

How do we solve this problem?

- Let's encrypt returns account URI: https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu (Just an example and does not represent the actual content.)

    - base32(SHA-256(https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu)[0:9])

- GTS returns a different account URI: https://acme-02.pki.google/account/ilctdkn9ifnueocs (Just an example and does not represent the actual content.)

    - base32(SHA-256(https://acme-02.pki.google/account/ilctdkn9ifnueocs)[0:9])

This situation (scenario of Cloudflare's multiple backup certificate) CA requires two different dnshostname, and Cloudflare customers need to create DNS record twice.

Is there other way to reduce configuration overhead for users?

Thank you.

[Amir Omidi (aaomidi)]

I personally think its okay if the customer has to make multiple DNS records for DCV delegation. This isn't unprecedented, as it's commonly used in DNS (e.g multiple MX records, DNS based load balancing, etc). Is there a reason why the DNS setup for this should be different than the existing practices used in DNS?

Thanks!

[Ryan Hurst]

Remember that an ACME account key is just another cryptographic key that requires full lifecycle management. This involves keeping it secure, rotating it regularly to limit the window an attacker has if it is ever compromised, and eventually replacing it with a key using stronger or newer algorithms (for example, moving to ML-DSA for post-quantum security). In practice, ACME account keys are no more secure than the keys used for TLS certificates, since most implementations store them on disk protected only by basic filesystem ACLs. 

On the positive side, because account keys see fewer operations, they can be generated and stored in hardware such as a TPM, which offers stronger protection without impacting TLS performance or algorithm choices. This is why it makes sense to decouple the domain-control label from the account key itself, but the specification must still acknowledge that these keys require proper management. Failing to do so would lead to fragile implementations and discourage sound key-management practices.

Ryan

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7ea62291-2e4c-4500-a4b2-d0d7ed7a43d7n%40mozilla.org.

[Xiaohui Lam]

Hi Amir, and Ryan

I agree with your comments.

Yes ACME account key needs full lifecycle management(including replace mechanism).

Maybe my demand can be satisfied by a new challenge type, rather than the digest form generated based on accountkey.

e.g:  design a new challenge type`dns-delegation-01`

And Domain name's challenges API:

POST /acme/authz/PAniVnsZcis HTTP/1.1

Host: example.com

Content-Type: application/jose+json

{

"protected": base64url({

"alg": "ES256",

"kid": "https://example.com/acme/acct/evOfKhNU60wg",

"nonce": "uQpSjlRb4vQVCjVYAyyUWg",

"url": "https://example.com/acme/authz/PAniVnsZcis"

}),

"payload": "",

"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"

}

HTTP/1.1 200 OK

Content-Type: application/json

Link: <https://example.com/acme/directory>;rel="index"

{

"status": "pending",

"expires": "2016-01-02T14:09:30Z",

"identifier": {

"type": "dns",

"value": "www.example.org"

},

"challenges": [

{

"type": "http-01",

"url": "https://example.com/acme/chall/prV_B7yEyA4",

"token": "DGyRejmCefe7v4NfDGDKfA"

},

{

"type": "dns-01",

"url": "https://example.com/acme/chall/Rg5dV14Gh1Q",

"token": "DGyRejmCefe7v4NfDGDKfA"

},

{

"type": "dns-delegation-01",

"url": "https://example.com/acme/chall/D2zX3m9jfIyE4",

"token": "DGyRejmCefe7v4NfDGDKfA"

}

]

}

And requires user to create DNS TXT

_acme-challenge_cloudflare.www.example.org  300 TXT keyAuthorization=token || '.' || base64url(Thumbprint(accountKey))

And perform challenge(delegation can only be alphanumeric, no special characters allowed):

POST /acme/chall/D2zX3m9jfIyE4 HTTP/1.1 Host: example.com Content-Type: application/jose+json { "protected": base64url({ "alg": "ES256", "kid": "https://example.com/acme/acct/evOfKhNU60wg", "nonce": "Q_s3MWoqT05TrdkM2MTDcw", "url": "https://example.com/acme/chall/D2zX3m9jfIyE4" }), "payload": base64url({


"delegation": "cloudflare"



}), "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" }

How about new challenge type like this? But we need a draft a new RFC if it makes sense.

Thanks

[Amir Omidi]

Is the primary reason for this so we don’t have to have the user specify multiple DNS records? If so I don’t think this added complexity makes sense here.

[Ryan Hurst]

Hi Xiaohui,

Anyone is welcome to propose a new ACME challenge, but I am not sure I see a problem that needs solving.

- Multiple DNS records are normal. DNS is designed to store many RRsets for the same owner name. Delegation operators already publish dozens of A, AAAA, and TXT records for a single zone. Adding one more CNAME for a second CA is not an operational burden.

- Automation already has to write DNS. Modern deployment models rely on fully automated issuance and renewal. If a CA uses ARI (RFC 9270) or the account holder needs to re-key, the automation must add or update DNS TXT records anyway. Whether there is one record or two makes no difference to that workflow.

Extra challenge types add complexity. Every new challenge means code, documentation, compliance review, and interop testing for ACME clients and CAs. That overhead should buy real security or usability gains. Here the benefit seems to be avoiding a second record, which does not look compelling from my perspective.

If there is a concrete scenario where two CNAMEs cause material pain like rate limits, cache issues, legacy software it would help to understand what that issue is. Otherwise the existing dns-01 plus the delegated-label draft appear to meet the goal without adding a third option to maintain.

Best,
Ryan

[Jesper Kristensen]

I cannot see how a few extra DNS records creates a problem, but I can imagine the timing of when these records need to be changed could cause a problem in some scenarios. For example when a hosting provider needs to change CAs, they would need to ask all customers using this validation method to update their CNAMEs at the same time. Cloudflare, which was given as the example, has changed CAs on short notice in the past when the Let's Encrypt cross-sign expired, so I don't think it is entirely theoretical. Another more hypothetical example could be if the hosting provider needed to change ACME accounts depending on the customer's jurisdiction or other reasons.

I guess it may be possible to work around these limitations some of the time, but it feels strange that hosting providers have to do that, when there is no reason why this restriction was created in this validation method.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwZddyDwGB0WMCFLzEJg531gqV%3D7Vn1EG0WRn60Ncy%2BHRg%40mail.gmail.com.

[Amir Omidi]

> I guess it may be possible to work around these limitations some of the time, but it feels strange that hosting providers have to do that, when there is no reason why this restriction was created in this validation method.

I mean, I wouldn't say no reason. Note that this new method does not deprecate DNS-01, so the normal DNS-01 challenge works. This method merely aims to allow doing DCV delegation to more than one entity.

We needed a stable(ish) value that both the subscriber and the CA have access to. Account URI was chosen because it fit that criteria.

The idea for these hosting providers is that they should preferably have multiple CA options configured beforehand. But yes, new providers would require a manual update.

[Xiaohui Lam]

Hi all,

I’ve seen a BR/servercert fork and PR created by Michael Slaughter (https://github.com/slghtr-says/servercert/pull/3/files) that may be helpful for ACME delegation ultilizing service providers (such as Cloudflare). This PR introduces support for static DNS TXT record delegation with a persistent hostname, enabling the delegation of specific account URIs authorized to issue certificates for a domain name.
This approach leverages DNS TXT records with structured values to explicitly map domain control to designated account URIs, more secure granular control to enhancing both security and scalability for domain validation workflows.

[Matt Palmer]

On Wed, May 14, 2025 at 08:57:12AM -0700, Xiaohui Lam wrote:
> Based on my experience, instances of ACME account key compromise are
> extremely rare.

I don't know what you consider "rare", but I've cancelled hundreds[1] of
Let's Encrypt accounts whose private keys were publicly disclosed. As a
percentage of all LE accounts, perhaps it's not huge, but it's certainly far
greater than the zero that would be needed to be able to claim that a
public key is a long-term stable identifier -- and that's before we
consider the need to periodically rotate keys (for whatever reason).

> I also have full confidence in Cloudflare’s robust security
> operations capability - such account key compromises are highly unlikely to
> occur internally at Cloudflare.

Since the I-D is not applicable only to Cloudflare, this argument is not
particularly persuasive.

> My suggestion is to draft the document to retain both the current account
> URI-generated suffix and add an account key-generated suffix. This would
> allow delegate operators (such as Cloudflare) to implement the optimal
> approach for their customers.

I strongly disagree with this suggestion. Complexity is the enemy of
security, and flexibility has a nasty habit of coming back to cause
problems.

- Matt

[1] I don't keep a tally, but for a period of several years I was doing
one every couple of days -- sometimes multiple per day -- so "hundreds"
is not an unreasonable estimate.

[Xiaohui Lam]

Hi Matt,

Thanks for your participation in the discussion.
I think rare is just my personal habit of using ACME and I have never replace account key.
But I agree with your point: Rare doesn't mean won't happen.

Regards.
Bruce