Re: [Acme] DNS-ACCOUNT-01 Updates

[Seo Suchan <[e-mail]>]

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 list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme