I don't spend a lot of time on the Let's Encrypt forums, but I do maintain an internal ACME server and work with the IT staff that manage certs/acme client installs. Most of my users are only vaguely aware that their ACME client creates an account as part of the process. Given that, I suspect they would find the name 'DNS-ACCOUNT-01' confusing as it wouldn't be clear to them which account is being referred to. They would likely assume it would be the account on their DNS provider. I think 'DNS-02' as a newer version of the DNS challenge type would be less confusing. ________________________________ From: Acme <[email protected]> on behalf of Amir Omidi <[email protected]> Sent: Thursday, May 18, 2023 5:03 PM To: Seo Suchan <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Acme] DNS-ACCOUNT-01 Updates
I think what decision happens here will probably end up setting the precedent on either these digits are "version numbers" of the "base challenge types" (Not sure what to call them), and they act as a replacement of them. Or that they are another flavor of the technologies/protocols used in those challenges. I do not have strong opinions here either way. Another factor to consider is how would support/Q&A forums feel about the name choice of DNS-ACCOUNT-01 vs DNS-02. For example, if there is anyone here who's keeping an eye on the Let's Encrypt's community forum do you think DNS-02 would make things easier or harder for users adopting ACME based certificate issuance and the folks helping them out? If harder, do you think DNS-ACCOUNT-01 would be a better option here? On Sat, May 13, 2023 at 5:24 AM Seo Suchan <[email protected]<mailto:[email protected]>> wrote: I kinda think TLS-SNI-02 was made as version 2 of TLS-SNI-01, but it doesn't matter as they are no longer a thing 2023-05-13 오전 3:43에 Q Misell 이(가) 쓴 글: I'm also in favour of calling it DNS-02. I highly doubt there will be many (if any) versions of challenges beyond version 1. It makes more sense to me to read DNS-02 and DNS challenge type 2, not a upgraded edition of version 1. ________________________________ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574<https://urldefense.com/v3/__https://find-and-update.company-information.service.gov.uk/company/12417574__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLMzA2bpN$>. ICO register №: ZA782876<https://urldefense.com/v3/__https://ico.org.uk/ESDWebPages/Entry/ZA782876__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLKSmK3R2$>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Fri, 12 May 2023 at 17:58, Aaron Gable <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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<https://urldefense.com/v3/__https://archive.cabforum.org/pipermail/validation/2023-May/001892.html__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLJ-dXGZ7$> [1] : https://daknob.github.io/draft-todo-chariton-dns-account-01/<https://urldefense.com/v3/__https://daknob.github.io/draft-todo-chariton-dns-account-01/__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLAIe3NHy$> _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$> _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$> _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$> _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
