Remove DNS-02, elaborate on security benefits #45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jdkasten
reviewed
Sep 21, 2024
| @@ -66,15 +66,11 @@ Furthermore, since each domain only has a single authorization label, it creates | |||
|
|
|||
| In multi-region deployments, where separate availability zones serve the same content, and dependencies across them are avoided, operators need a way to obtain a separate certificate per zone, for the same domain name. Similarly, in cases of zero-downtime migration, two different setups of the infrastructure may coexist for a long period of time, and both need access to valid certificates. | |||
|
|
|||
| This document specifies two new challenge types. `dns-02` and `dns-account-01`, which aim to address these deficiencies. | |||
| This document specifies the `dns-account-01` validation method, which aim to address these deficiencies. | |||
There was a problem hiding this comment.
Suggested change
| This document specifies the `dns-account-01` validation method, which aim to address these deficiencies. | |
| This document specifies the `dns-account-01` validation method, which aims to address these deficiencies. |
| ## DNS-02 | ||
|
|
||
| The `dns-02` challenge adds onto `dns-01` by introducing a scoping mechanism to the domain authorization label. This allows for the client to specify if the intended domain validation is for a specific host, a wildcard domain, or a domain and all of its subdomains. | ||
| This RFC does not intend to deprecate the `dns-01` challenge specified in {{!RFC8555}}. Since these new challenges do not modify any pre-existing challenges, the ability to complete the `dns-account-01` challenge requires ACME server operators to deploy new changes to their codebase. This makes adopting and using these challenges an opt-in process. |
There was a problem hiding this comment.
Suggested change
| This RFC does not intend to deprecate the `dns-01` challenge specified in {{!RFC8555}}. Since these new challenges do not modify any pre-existing challenges, the ability to complete the `dns-account-01` challenge requires ACME server operators to deploy new changes to their codebase. This makes adopting and using these challenges an opt-in process. | |
| This RFC does not intend to deprecate the `dns-01` challenge specified in {{!RFC8555}}. The `dns-account--01` challenge requires ACME server operators to deploy new changes to their codebase and is an opt-in process. |
There was a problem hiding this comment.
Plural "challenges" was used a few times in these sentences. I also find it a bit awkward so I tried to simplify the text without losing meaning. I think there is still room for improvement on it. Feel free to further edit.
| In both `dns-account-01` and `dns-02`, the same security considerations apply for the integrity of authorizations ({{!RFC8555, Section 10.2}}) and DNS security ({{!RFC8555, Section 11.2}}) as in the original specification for `dns-01`. They both differ from `dns-01` in that the challenges are scoped to the particular name being validated without relying upon CAA ({{!RFC8659}}). | ||
| The new `dns-account-01` challenge shares the same security considerations as the original `dns-01` specification regarding the integrity of authorizations {{!RFC8555, Section 10.2}} and DNS security {{!RFC8555, Section 11.2}}. | ||
|
|
||
| The `dns-account-01` challenge differs from the original specification by scoping the challenge to the specific name being validated, without relying on CAA records {{!RFC8659}}. This modification enables an ACME client to verify and validate an ACME server's operations with respect to the DNS names it queries. |
There was a problem hiding this comment.
Suggested change
| The `dns-account-01` challenge differs from the original specification by scoping the challenge to the specific name being validated, without relying on CAA records {{!RFC8659}}. This modification enables an ACME client to verify and validate an ACME server's operations with respect to the DNS names it queries. | |
| The `dns-account-01` challenge differs from the `dns-01` challenge by scoping the authorization to the specific name being validated, without relying on CAA records {{!RFC8659}}. This modification enables an ACME client to verify and validate an ACME server's operations with respect to the DNS names it queries. |
| In both `dns-account-01` and `dns-02`, the same security considerations apply for the integrity of authorizations ({{!RFC8555, Section 10.2}}) and DNS security ({{!RFC8555, Section 11.2}}) as in the original specification for `dns-01`. They both differ from `dns-01` in that the challenges are scoped to the particular name being validated without relying upon CAA ({{!RFC8659}}). | ||
| The new `dns-account-01` challenge shares the same security considerations as the original `dns-01` specification regarding the integrity of authorizations {{!RFC8555, Section 10.2}} and DNS security {{!RFC8555, Section 11.2}}. | ||
|
|
||
| The `dns-account-01` challenge differs from the original specification by scoping the challenge to the specific name being validated, without relying on CAA records {{!RFC8659}}. This modification enables an ACME client to verify and validate an ACME server's operations with respect to the DNS names it queries. |
There was a problem hiding this comment.
This modification enables an ACME client to verify and validate an ACME server's operations with respect to the DNS names it queries.
This alone does not verify the server is performing correctly and only grants authorization to the intended identifier or performs its job ultimately correctly according to policy? I am not sure I fully understand the benefit.
There was a problem hiding this comment.
I think we could pull/reference language from the "best practice" draft depending on what we keep.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.