Re: [Acme] DNS-ACCOUNT-01 Updates

[Deb Cooley <[e-mail]>]

What is confusing is having a numerical value as part of the draft title.
Currently:  draft-ietf-acme-dns-account-01-01 which is only going to be
worse as the draft moves through version numbers.  My suggestion would be
to name it without the use of a numerical value.  This gets rid of both
problems.  The only question is what to actually call it.

Deb Cooley (no hats)
[e-mail]



On Fri, May 19, 2023 at 8:38 AM Sean Dilda <[e-mail]> wrote:

> 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 <[e-mail]> on behalf of Amir Omidi <aaomidi=
> [e-mail]>
> *Sent:* Thursday, May 18, 2023 5:03 PM
> *To:* Seo Suchan <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *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 <[e-mail]> 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 <aaron=
> [e-mail]> 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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$>
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$>
>
>
> _______________________________________________
> Acme mailing [e-mail]://www.ietf.org/mailman/listinfo/acme <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$>
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!r1rAJU8Y16wsZhu9vZIYkTsR0gQG3x5k5iniyAWsEcG3EL1ott1SAH_t6KkJBohTGUxArlzOHToU5usEHb4eLIdl8lBK$>
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>