For what it's worth, I'm in favor of calling it DNS-02. Despite your totally correct descriptions of the disadvantages of this new method, I *do* still view it as a generally-improved version of DNS-01. It's obviously backwards-incompatible, hence the new major version number, but it is generally an improvement that creates more flexibility for clients at little cost. I also find the name "DNS-ACCOUNT-01" to be slightly unfortunate, as no "dns accounts" are involved -- it makes sense once you understand the method, but the name gives little to no hint to how the method works on its own.
Aaron On Thu, May 11, 2023 at 4:52 PM Antonios Chariton <[email protected]> wrote: > Hello everyone, > > I’m sending this e-mail to the list to update you all on DNS-ACCOUNT-01 > and the news we have since the presentation in IETF 116. > > You can all help by reviewing the text[0], these updates, and sharing your > opinion in this thread here! > > The CA/B Forum 2023-05-04 meeting discussed DNS-ACCOUNT-01 and three > things came out of it, as it is evident in the minutes[1]: > > 1) This method is compatible with the CA/B Forum Baseline Requirements > that are binding for all WebPKI CAs, specifically section 3.2.2.4.7 for > agreed-upon change to a DNS record. This means that CAs can start using > this standard immediately, and there are no other dependencies. The design > seemed to be good in its current version. Obviously, quick changes to their > CP/CPS may be required, but this is not blocking and unilateral. > > 2) There is a documented need for various usecases where this challenge > would help, from several stakeholders, and evidence that it could be > beneficial to the ecosystem and its development. It allows ACME to be used > in even more situations where more traditional and non-automatable methods > had to be relied upon. > > 3) There was a suggestion to rename this challenge to DNS-02. This is > something that we had rejected back when we created this challenge, however > it has been suggested several times, so we are happy to reconsider this. It > may be the right choice. > > There’s no published precedence of what -02 means right now, so it’s > unclear whether it is a second option, or a next generation / improved > challenge. We never planned to replace DNS-01 with our challenge, we always > intended to add more options, and cover more use cases. Here are some > technical “disadvantages” of this work vs DNS-01: > > 1) ACME Clients need to calculate the correct label. Although we provide > the algorithm, a bash script, and test vectors, anecdotal data from ISRG > suggest that some clients still mess things up (implementing RFC 8555), so > this is another value where this may happen. An easy solution here would be > to share the expected label with the client, but we decided against this to > protect against cross-protocol attacks, and also to protect the client > against an ACME server giving it arbitrary DNS records to change. If > clients calculate this independently, they don’t need to trust the server. > > 2) The label is longer, so some very very long domain names may no longer > work. Since this is 17 characters longer than DNS-01’s label, anything > approaching the various limits (of DNS, etc.) may break. For example, if in > DNS-01 you end up with a 236-253 character domain name to check for the TXT > record, then DNS-ACCOUNT-01 will go over the limit and won’t work. We don’t > consider this to be a major problem. We’re also not aware of many domain > names in the 236-253 character range. > > 3) If an ACME client for whatever reason loses access to the ACME account, > this “set and forget” DNS label now has to change. Things would break here > with other standards too (if you need an EAB token, you can’t create a new > account anyways, if you limit the ACME account via CAA records, you can’t > issue, etc.) but DNS-ACCOUNT-01 would just add to the things that would > have to be taken into account. We don’t currently consider this a huge > issue, but if you think it could be, let us know. > > As you can see, these 3 tradeoffs above had to be made, to ensure we can > cover more use cases. We think these are good tradeoffs for an additional > ACME challenge, but perhaps they are not for an “upgraded” one. > > What do you think about the naming? Do you perceive “DNS-02” as an > improved version, or as a second option? We are happy to rename this to > DNS-02 and we have no plans of breaking any ACME server or client already > using DNS-01 :) > > Thanks for reading through this, and I am happy to hear your thoughts and > get reviews on the draft, so we can move further with this work. > > Antonios Chariton > Independent Contributor ;) > > - - - > Links: > > [0] : > https://archive.cabforum.org/pipermail/validation/2023-May/001892.html > [1] : https://daknob.github.io/draft-todo-chariton-dns-account-01/ > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
