The decision to remove the scoping mechanism from this draft was driven by two key considerations:
First, the initial purpose of this draft was to solve a specific problem for large ACME integrators: enabling high-availability ACME certificate issuance systems for domains used across multiple systems. Adding additional scoping fields would introduce complexity to both ACME clients and servers - potentially delaying this core solution. Feedback I had received both through the mailing list and privately told me that this new challenge is necessary to fill a gap that currently exists within ACME. Second, while security improvements are valuable and welcome, I believe they deserve dedicated attention in separate RFCs that can thoroughly explore and implement them without compromising backwards compatibility. I encourage and welcome future work in this space that focuses specifically on enhancing the security properties of these methods. > On Nov 26, 2024, at 5:57 PM, Erik Nygren <erik+i...@nygren.org> wrote: > > 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 <wtha...@gmail.com > <mailto:wtha...@gmail.com>> 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=40aaomidi....@dmarc.ietf.org <mailto:40aaomidi....@dmarc.ietf.org>> >> 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 -- acme@ietf.org <mailto:acme@ietf.org> >>> To unsubscribe send an email to acme-le...@ietf.org >>> <mailto:acme-le...@ietf.org> >> _______________________________________________ >> Acme mailing list -- acme@ietf.org <mailto:acme@ietf.org> >> To unsubscribe send an email to acme-le...@ietf.org >> <mailto:acme-le...@ietf.org>
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
