[Acme] Re: DNS-ACCOUNT Challenge Update

[Erik Nygren <[e-mail]>]

What is the rationale for removing the scoping mechanism?
As an operator that is using ACME, that is also a recurring problem that
introduces risk
that limits some use-cases (specifically it makes it more risky to use
ACME) .

At a minimum it would be good to call out this risk in Security
Considerations.
The rationale is called out in
draft-ietf-dnsop-domain-verification-techniques (
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06
).

I can see why domain-challenge might not be relevant for the ACME use-case,
leaving primarily the host and wildcard cases.


Specifically (pasting from that draft):

4.
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#section-4>Scope
of Validation
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#name-scope-of-validation>
*For
security reasons, it is crucial to understand the scope of the domain name
being validated. Both Application Service Providers and the User need to
clearly specify and understand whether the validation request is for a
single hostname, a wildcard (all hostnames immediately under that domain),
or for the entire domain and subdomains rooted at that name. This is
particularly important in large multi-tenant enterprises, where an
individual deployer of a service may not necessarily have operational
authority of an entire domain.*

*In the case of X.509 certificate issuance, the certificate signing request
and associated challenge are clear about whether they are for a single host
or a wildcard domain. Unfortunately, the ACME protocol's DNS-01 challenge
mechanism ([RFC8555 <https://www.rfc-editor.org/rfc/rfc8555>], Section 8.4
<https://rfc-editor.org/rfc/rfc8555#section-8.4>) does not differentiate
these cases in the DNS Validation Record. In the absence of this
distinction, the DNS administrator tasked with deploying the Validation
Record may need to explicitly confirm the details of the certificate
issuance request to make sure the certificate is not given broader
authority than the User intended. (The ACME protocol is addressing this in
[ACME-SCOPED-CHALLENGE
<https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/>].)*

*In the more general case of an Internet application service granting
authority to a domain owner, again no existing DNS challenge scheme makes
this distinction today. New applications should consider having different
application names for different scopes, as described below in Section 5.2.1
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#scope-indication>.
Regardless, services should very clearly indicate the scope of the
validation in their public documentation so that the domain administrator
can use this information to assess whether the Validation Record is
granting the appropriately scoped authority.*
5.2.1.
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#section-5.2.1>Scope
Indication
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#name-scope-indication>

*For applications that may apply more broadly than to a single hostname,
the RECOMMENDED approach is to differentiate the application-specific
underscore prefix labels to also include the scope (see Section 4
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-06#scope>).
In particular:*

-

*"_<PROVIDER_RELEVANT_NAME>-host-challenge.example.com
<http://host-challenge.example.com>" applies only to the specific hostname
of "example.com <http://example.com>" and not to anything underneath it.*
-

*"_<PROVIDER_RELEVANT_NAME>-wildcard-challenge.example.com
<http://wildcard-challenge.example.com>" applies to all hostnames at the
level immediately underneath "example.com <http://example.com>". For
example, it would apply to "foo.example.com <http://foo.example.com>" but
not "example.com <http://example.com>" nor "quux.bar.example.com
<http://quux.bar.example.com>"*

*[...]*

Best, Erik


On Tue, Nov 19, 2024 at 4:57 PM Wayne Thayer <[e-mail]> wrote:

> Thank you Amir. This draft solves a problem that is hindering adoption of
> ACME. I’ve reviewed it and am happy with the simplifications that place the
> focus on solving that one specific problem.
>
> In order for CAs to implement this new domain validation method, the CAB
> Forum’s TLS Baseline Requirements need to be updated. Unless concerns are
> posted in the next week or two that might result in material changes to the
> current draft, I will start a CAB Forum ballot to add dns-account-01 as an
> additional permitted validation method in the TLS baseline Requirements.
>
> Thanks,
>
> Wayne
>
> On Mon, Nov 18, 2024 at 9:50 AM Amir Omidi <amir=
> [e-mail]> wrote:
>
>> Hi everyone,
>>
>> Based on the feedback received, we've published a new version of the
>> DNS-ACCOUNT-01 draft (
>> https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/)
>> This version has been simplified by removing DNS-02 and the scoping
>> mechanism, focusing purely on enabling multiple concurrent ACME clients to
>> authorize the same domain.
>>
>> Key changes:
>>
>>    - Removed DNS-02 challenge type completely
>>    - Removed the scoping mechanism (host/wildcard/domain)
>>    - Simplified DNS record format
>>    - More focused introduction on the core problem of enabling multiple
>>    concurrent ACME clients
>>    - Better explanation of use cases like multi-region deployments
>>
>>
>> We welcome your feedback on these changes.
>>
>> Best regards,
>> Amir Omidi
>> _______________________________________________
>> Acme mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>