Hi Aaron and all, Thanks for your insight and support. These are good points and we as authors are looking forward to working with members of the ACME WG to discuss these points further.
One consideration for this proposal in light of real-world practices, is that in addition to the two motivations Aaron mentioned (overcoming operational challenges with http-01/tls-alpn-01 and dns-01/dns-account-01), there is a common "magic" CNAME behavior used by integrators/cloud providers (see https://www.fastly.com/documentation/guides/getting-started/domains/securing-domains/setting-up-tls-with-certificates-fastly-manages/ and the acme-dns.io hosted offering of https://github.com/joohoi/acme-dns ). This approach of using a magic CNAME 1) creates a single point of failure where a compromise of a CNAME service (potentially over the network via DNS attacks like cache poisoning or BGP attacks) could take down thousands of domains and 2) objectively expands the attack surface as both the domain in question or the CNAME service can be attacked. Thus, I think there is a security advantage of this protocol in addition to the operational advantages Aaron mentioned. Another perspective to consider is that should a subscriber automate the dns-01 challenge, there is a risk the subscriber will put unrestricted DNS API keys on their ACME client. This is not an ideal security configuration and avoiding the need for online keys on the ACME client is generally beneficial for security. Regarding the live control consideration (which I think should be discussed more), if a subscriber relies on a static CNAME for dns-01 validation, the validation similarly is no longer strictly demonstrating live control of the domain in question. Even for domains that do use dns-01 via direct zone file changes or rely on a different validation method, an adversary could utilize CNAME to permit continued validation even after losing control of a victim's zone file. We are hoping to continue to engage in more discussions along these lines with the ACME WG and work with the WG to integrate these motivations into the I-D. Best, Henry On Mon, Sep 29, 2025 at 6:42 PM Aaron Gable <aaron= [email protected]> wrote: > I support adopting this draft. > > I would articulate the two problems this draft is trying to solve as > follows: > 1. The webserver-based (http-01 and tls-alpn-01) challenges have > operational difficulties: some webmasters don't want to have port 80 open, > or use geo-ip blocking, or want to obtain a wildcard certificate (the > WebPKI appropriately does not allow using these methods to validate > wildcard names). > 2. The DNS-based (dns-01 and dns-account-01) challenges have operational > difficulties: DNS propagation can be slow, and many webmasters > (appropriately) don't want to have DNS API keys on the same host as their > ACME client (which is often on the same host as their webserver). > > So even regardless of the approach taken here, I think this problem space > is worth tackling. > > But beyond that, I think that this *solution* space is quite interesting, > and worth discussing as a Working Group. The key insight is that, because > ACME accounts are tightly bound to keypairs, ACME account URLs can be > durable and cryptographically-bound stand-ins for random tokens. Both this > method and the existing dns-01 show the same thing: the DNS operator > approves of the operator of a specific ACME account. > > Of course, there's one hiccup: they actually only show *almost* the same > thing. The dns-01 method shows that the DNS operator approves of the > operator of a given ACME account (the one to which the random token was > sent) *right now*. The proposed dns-persist-01 only demonstrates that the > DNS operator approved of the ACME account *at some point in the past*. > > But while I think that distinction is critical and worth discussing > extensively, I don't think it is disqualifying. In particular, I think that > the tradeoff here -- less proof-of-freshness in return for massive > operational simplification -- will result in large uptake of this > validation method and a large improvement to the security and privacy of > the web overall. > > Aaron > > On Fri, Sep 26, 2025 at 8:14 AM Mike Ounsworth via Datatracker < > [email protected]> wrote: > >> >> Subject: Call for adoption: draft-sheurich-acme-dns-persist-01 (Ends >> 2025-10-10) >> >> This message starts a 2-week Call for Adoption for this document. >> >> Abstract: >> This document specifies "dns-persist-01", a new validation method for >> the Automated Certificate Management Environment (ACME) protocol. >> This method allows a Certification Authority (CA) to verify control >> over a domain by confirming the presence of a persistent DNS TXT >> record containing CA and account identification information. This >> method is particularly suited for environments where traditional >> challenge methods are impractical, such as IoT deployments, multi- >> tenant platforms, and scenarios requiring batch certificate >> operations. The validation method is designed with a strong focus on >> security and robustness, incorporating widely adopted industry best >> practices for persistent domain control validation. This design aims >> to make it suitable for Certification Authorities operating under >> various policy environments, including those that align with the CA/ >> Browser Forum Baseline Requirements. >> >> File can be retrieved from: >> https://datatracker.ietf.org/doc/draft-sheurich-acme-dns-persist/ >> >> Please reply to this message keeping [email protected] in copy by indicating >> whether you support or not the adoption of this draft as a WG document. >> Comments to motivate your preference are highly appreciated. >> >> Authors, and WG participants in general, are reminded of the Intellectual >> Property Rights (IPR) disclosure obligations described in BCP 79 [2]. >> Appropriate IPR disclosures required for full conformance with the >> provisions >> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. >> Sanctions available for application to violators of IETF IPR Policy can be >> found at [3]. >> >> Thank you. >> [1] https://datatracker.ietf.org/doc/bcp78/ >> [2] https://datatracker.ietf.org/doc/bcp79/ >> [3] https://datatracker.ietf.org/doc/rfc6701/ >> >> >> >> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
