Proposing a new ACME challenge type: DNS-ACCOUNT-01

[Amir Omidi]

This message is to solicit opinions about a proposed new ACME challenge to address hosting environments where a user cannot easily prove control using existing methods, but could via an alternative DNS-based approach.

We have observed cases where customers want to restrict DNS changes for most of their domains and delegate the domain control validation through CNAMEs to a centralized location. However, with DNS-01 having a static label, these customers are prevented from being able to use CNAME delegation to integrate with more than one ACME CA for certificate issuance.

Being able to have multiple independent instances of an ACME client obtain certificates for the same domain is particularly important for High Availability deployments, where Subscribers often set up multiple independent serving stacks that integrate with multiple ACME CAs for failover and need a valid certificate in each of them.

The new challenge is called DNS-ACCOUNT-01 and it extends (but does not replace) DNS-01 in the following way: the DNS label under which the TXT record is created to respond to the challenge is account dependent. This allows a Subscriber to use multiple and separate subdomains to solve ACME challenges for the same domain.

We plan to submit this as a draft to the IETF for consideration, to make the challenge available to all CAs and promote its adoption in ACME clients.

The current draft is available here: https://daknob.github.io/draft-todo-chariton-dns-account-01/

A text version is available here: https://daknob.github.io/draft-todo-chariton-dns-account-01/draft.txt

In DNS-01, the CA checks for DNS records under _acme-challenge. In DNS-ACCOUNT-01, the CA will check for DNS records under _acme-challenge_accountUniqueValue, e.g. _acme-challenge_ujmmovf2vn55tgye. The last part is constructed from base32 encoding a part of the SHA-256 hash of the ACME Account URL. This allows each ACME account to use a separate subdomain for the TXT record. We believe that BR Method 3.2.2.4.7 can be used with the proposed challenge for proof of domain control.

We welcome any thoughts you may have on the matter and we will be happy to discuss this and move it forward.

[John Han]

How about use multiple TXT records for longer hash? like "_acme-challenge_accounts.example.com TXT [account hash]"

[Amir Omidi]

The main goal with this proposal is to be able to enable delegating domain control validation to multiple providers via CNAME. Since CNAMEs have to be unique in a DNS Zone, we're left with modifying the label of the TXT record.

[Ryan Hurst]

I would add last I looked at a reasonable number of the ACME clients make the assumption that there is a single TXT record and do not enumerate over all records. 

--
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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/176e3faa-f19d-42e4-bc93-d89f2cb0fb8bn%40mozilla.org.

[John Han]

oh that makes sense. But I still can't get it.
if user use "_acme-challenge.example.com IN CNAME example.com.validation.com", you can set TXT records like this.
example.com.validation.com TXT [ACME client 1]
example.com.validation.com TXT [ACME client 2]
...
example.com.validation.com TXT [ACME client n]
since RFC8555 only requires " Verify that the contents of one of the TXT records match the digest value". After validation, ACME clients just remove what they write into DNS.

Should I missed something?

[John Han]

It's ok if ACME server works fine (enumerate all TXT records.)
We can address this issue in CA's acme usage or by other means since TXT records are rarely used unless they configure Email or participate validation process.

[Ryan Hurst]

Clients do not have this removal behavior today, and there is still the issue of multiple providers and delegation of initiating the validation to hosting providers.

--

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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/162fba26-bfe0-4cdf-a9fe-e57ec02a38fbn%40mozilla.org.