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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
