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=40letsencrypt....@dmarc.ietf.org> 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
<daknob....@gmail.com> 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
