Re: [Acme] DNS-ACCOUNT-01 Updates

[Amir Omidi <[e-mail]>]

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://find-and-update.company-information.service.gov.uk/company/12417574>.
> ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>.
> 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
>>> [1] : https://daknob.github.io/draft-todo-chariton-dns-account-01/
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
> _______________________________________________
> Acme mailing [e-mail]://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>