Since I now realize that I forgot to say this in my previous message: Let's Encrypt plans to implement the server side of dns-persist in 2026. We believe that it will provide a real benefit to our ACME clients, especially in concert with the WebPKI reducing validation data reuse periods over the next couple years.
Aaron On Thu, Oct 9, 2025 at 8:51 AM Henry Birge-Lee <birgelee= [email protected]> wrote: > Hi all, > > Michael Slaughter's ballot for this in the CA/Browser Forum is making > great progress with (what I believe is) unanimous support and sufficient > browser support (2 certificate consumer votes) to pass. It is likely the > voting (which concludes tomorrow) will pass and it will enter IP review. > > I have already gotten a commitment to implement this in private from a > very large ACME CA. > > Shiloh has already pushed initial test implementations for a client and a > CA that interoperate. ( > https://mailarchive.ietf.org/arch/msg/acme/X7eWneZfFRk19hNg7LuITzlIlk8/ ) > . Shiloh also represents Fastly/Certainly, another large ACME CA that will > very likely be implementing. Slaughter represents Amazon Trust Services > which I would also expect to implement. Both Amazon and Fastly additionally > run massive numbers of ACME clients which allows them to deploy the other > side of this protocol as well. > > In addition, there is a "no RFC" way of doing this in ACME which several > CAs have already brought to my attention: check DNS persist records in > advance and then provide no challenges to the ACME client if there is a > record. This requires no client modification but comes at a performance > overhead and eliminates the client's ability to choose which challenge to > use which is a part of the ACME protocol. If this technique is adopted in > production without this I-D moving forward there would be no IETF guidance > around this type of behavior. > > *Independent of the IETF's decision to adopt, I feel there is high > likelihood this technique will be used in production at several large CAs* > based on implementation interest I have received by various CAs and the > popularity of the dns-01 with CNAME technique which shows the desire for a > static DCV-related record. Implementation without an IETF draft would mean > either 1) implementation only by non-ACME CAs which gives a disadvantage to > the ACME protocol as there are legitimate use cases for doing this, 2) > implementation using the "no RFC" approach discussed above without any IETF > input, or 3) implementation based on a personal, non-adopted I-D. To me all > three of these outcomes feel subpar. > > Based on my talk at IETF 123, I had gotten the impression that the ACME WG > was interested in providing input on this standard and this approach more > generally. We felt IETF involvement would be beneficial to the community > which is why we brought this to the IETF. I encourage members of the > working group to see this as an opportunity to contribute and improve on a > standard that is already moving forward in other ecosystems. We want to > work with the IETF community and have incorporated all feedback to date/are > hoping for the opportunity to improve this further post adoption. > > Best, > Henry > > > On Tue, Sep 30, 2025 at 10:06 AM Michael Richardson <[email protected]> > wrote: > >> >> Henry Birge-Lee <[email protected]> wrote: >> > and the acme-dns.io hosted offering of >> https://github.com/joohoi/acme-dns ). >> >> Oh, yes, I knew about this, but since I already had debugged nsupdate, and >> could copy and paste that configuration, I never returned to that. >> >> > 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 >> >> DNSSEC solves some of those sins. >> And the auxiliary zone is much easier to DNSSEC sign. >> >> > 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. >> >> I'm hearing that we might need/want CSR-attestation-like mechanism for >> ACME account and API keys too :-) >> >> -- >> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting >> ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> >> _______________________________________________ > 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]
