From 23cf066bbb1083a37f0b3b2253c580a5b63d7fcb Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 1 Sep 2023 14:14:06 -0400 Subject: [PATCH 01/43] Change how the validation label is constructed --- draft-ietf-acme-dns-account-01.mkd | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index c1cdb0b..777f5d4 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -120,9 +120,9 @@ A client can fulfill this challenge by performing the following steps: - Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization -- Construct the validation domain name by prepending the following label to the domain name being validated: +- Construct the validation domain name by prefixing the following label to the domain name being validated: - "_acme-challenge_" || base32(SHA-256(Account Resource URL)[0:9]) + "_" || base32(SHA-256(Account Resource URL)[0:9]) || "_acme-challenge_" - SHA-256 is the SHA hashing operation defined in {{!RFC6234}} - `[0:9]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA256 operation @@ -135,7 +135,7 @@ A client can fulfill this challenge by performing the following steps: For example, if the domain name being validated is "www.example.org", and the account URL of "https://example.com/acme/acct/ExampleAccount" then the client would provision the following DNS record: ~~~ -_acme-challenge_ujmmovf2vn55tgye.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" +_ujmmovf2vn55tgye._acme-challenge.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" ~~~ (In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) @@ -194,18 +194,6 @@ The first 10 bytes were picked as a tradeoff: the value needs to be short enough # IANA Considerations -## DNS Parameters - -The Underscored and Globally Scoped DNS Node Names is to be updated to include the following entry: - -~~~ -RR Type: TXT -_NODE NAME: _acme-challenge_* -Reference: This document -~~~ - -Where `_acme-challenge_*` denotes all node names beginning with the string `_acme-challenge_`. It does NOT refer to a DNS wildcard specification. - ## ACME Validation Method The "ACME Validation Methods" registry is to be updated to include the following entry: From ca38d9d9a9fd3c3043cb59c2e99c70e63ca8a271 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 1 Sep 2023 15:56:01 -0400 Subject: [PATCH 02/43] Stray underline --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 777f5d4..a672c2a 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -122,7 +122,7 @@ A client can fulfill this challenge by performing the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization - Construct the validation domain name by prefixing the following label to the domain name being validated: - "_" || base32(SHA-256(Account Resource URL)[0:9]) || "_acme-challenge_" + "_" || base32(SHA-256(Account Resource URL)[0:9]) || "_acme-challenge" - SHA-256 is the SHA hashing operation defined in {{!RFC6234}} - `[0:9]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA256 operation From ca6ef161c572868ebea76e058c55f4c49801a039 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 1 Sep 2023 16:15:46 -0400 Subject: [PATCH 03/43] prefixing -> prepending --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index a672c2a..6d69db3 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -120,7 +120,7 @@ A client can fulfill this challenge by performing the following steps: - Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization -- Construct the validation domain name by prefixing the following label to the domain name being validated: +- Construct the validation domain name by prepending the following label to the domain name being validated: "_" || base32(SHA-256(Account Resource URL)[0:9]) || "_acme-challenge" From 17dfe71cd266370c7a48ab7a748bf2edaac2bfd7 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Thu, 7 Sep 2023 17:28:20 -0400 Subject: [PATCH 04/43] Review changes --- draft-ietf-acme-dns-account-01.mkd | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 6d69db3..dd8601a 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -122,17 +122,17 @@ A client can fulfill this challenge by performing the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization - Construct the validation domain name by prepending the following label to the domain name being validated: - "_" || base32(SHA-256(Account Resource URL)[0:9]) || "_acme-challenge" + "_" || base32(SHA-256(Account Resource URL)[0:9]) || "._acme-challenge" - SHA-256 is the SHA hashing operation defined in {{!RFC6234}} - `[0:9]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA256 operation - base32 is the operation defined in {{!RFC4648}} - - Account Resource URL is defined in {{!RFC8555, Section 7.3}} as the value in the Location header field + - Account Resource URL is defined in {{!RFC8555, Section 7.3}} as the value in the `Location` header field - The `"||"` operator indicates concatenation of strings - Provision a DNS `TXT` record with the base64url digest value under the constructed domain validation name -For example, if the domain name being validated is "www.example.org", and the account URL of "https://example.com/acme/acct/ExampleAccount" then the client would provision the following DNS record: +For example, if the domain name being validated is `www.example.org`, and the account URL of `https://example.com/acme/acct/ExampleAccount` then the client would provision the following DNS record: ~~~ _ujmmovf2vn55tgye._acme-challenge.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" From c95a7d18d16d3471f902153aa7eeccbf6a2be08c Mon Sep 17 00:00:00 2001 From: "Antonios A. Chariton" <743648+daknob@users.noreply.github.com> Date: Fri, 8 Sep 2023 02:36:59 +0300 Subject: [PATCH 05/43] Add explanation on implementation consideration (#28) --- draft-ietf-acme-dns-account-01.mkd | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index c06092b..ff3b092 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -182,6 +182,8 @@ If the server is unable to find a `TXT` record for the validation domain name, i As this challenge creates strong dependency on the `kid` account identifier, the server SHOULD ensure that the account identifier is not changed during the lifetime of the account. +If this change occurs, the existing long-term `CNAME` records created by all account holders will no longer be valid. The clients will not be able to issue certificates automatically moving forward. + # Security Considerations As this challenge that is introduced only differs in the left-most label of the domain name from the existing `dns-01` challenge, the same security considerations apply. From 9a6ea88fdfdbd1766e3e0c3991d01f4aaf493d83 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 15 Dec 2023 15:42:23 -0500 Subject: [PATCH 06/43] Update Amir's Company (#30) * Update Amir's Company --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index ff3b092..012d0c8 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -24,7 +24,7 @@ author: email: daknob@daknob.net - fullname: Amir A. Omidi - organization: Google + organization: Spirl email: aaomidi@google.com - fullname: James Kasten From 2fe6bbde13bffbdee49ce0c4af86d05504e4dae9 Mon Sep 17 00:00:00 2001 From: James Kasten Date: Tue, 9 Jan 2024 06:09:03 +0000 Subject: [PATCH 07/43] Add security considerations for new label scheme. --- draft-ietf-acme-dns-account-01.mkd | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 012d0c8..57915d4 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -48,6 +48,7 @@ normative: org: National Institute of Standards and Technology informative: + I-D.draft-ietf-dnsop-domain-verification-techniques: --- abstract @@ -90,6 +91,10 @@ label depends on the ACME account and not the account key, to allow for seamless account key rollover without the label changing. This ensures very long-lived labels, without any security considerations. +Finally, this work follows all recommendations set forth in "Domain Control Validation +using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. In particular, unlike `dns-01`, each validation is scoped to +the particular label being validated. + This RFC does not intend to deprecate the `dns-01` challenge specified in {{!RFC8555}}. Since this new challenge does not modify or build on any pre-existing challenges, the ability to complete the `dns-account-01` challenge @@ -186,13 +191,13 @@ If this change occurs, the existing long-term `CNAME` records created by all acc # Security Considerations -As this challenge that is introduced only differs in the left-most label of the domain name from the existing `dns-01` challenge, the same security considerations apply. +This challenge follows the general recommendations set out in "Domain Control Validation using DNS" {{I-D.draft-ietf-dnsop-domain-verification-techniques}} for supporting multiple intermediates within the context of {{!RFC8555}}. `dns-account-01` does not attempt to introduce a "scope of validation" to the identifier for simplicity, consistency with `dns-01`, and the fact that validations can be scoped effectively via CAA records in its primary use case, the Web PKI {{?RFC8657}}. -In terms of the construction of the label prepended to the domain name, there is no need for a cryptographic hash. The purpose of that is to create a long-lived and statistically distinctive record of minimal size. +`dns-account-01` only differs from `dns-01` in the addition of the left-most label so 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. -SHA-256 was picked due to its broad adoption, hardware support, and existing need in implementations that would likely support `dns-account-01`. +In terms of the construction of the label prepended to the domain name, there is no need for a cryptographic hash. The purpose of that is to create a long-lived and statistically distinctive record of minimal size. SHA-256 was picked due to its broad adoption, hardware support, and existing need in implementations that would likely support `dns-account-01`. -The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS record and response size, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. +The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS record and response size, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. # IANA Considerations From 9a0b41ad45c5a36a8abc4519bf463a5574b70b24 Mon Sep 17 00:00:00 2001 From: James Kasten Date: Tue, 9 Jan 2024 07:13:24 +0000 Subject: [PATCH 08/43] Rough draft of incorporating scoped challenges --- draft-ietf-acme-dns-account-01.mkd | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 57915d4..e496ca5 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -91,9 +91,10 @@ label depends on the ACME account and not the account key, to allow for seamless account key rollover without the label changing. This ensures very long-lived labels, without any security considerations. -Finally, this work follows all recommendations set forth in "Domain Control Validation -using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. In particular, unlike `dns-01`, each validation is scoped to -the particular label being validated. +Finally, this work follows all recommendations set forth in "Domain Control +Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. +In particular, unlike `dns-01`, each validation is scoped to the particular +label being validated. This RFC does not intend to deprecate the `dns-01` challenge specified in {{!RFC8555}}. Since this new challenge does not modify or build on any @@ -127,12 +128,16 @@ A client can fulfill this challenge by performing the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization - Construct the validation domain name by prepending the following label to the domain name being validated: - "_" || base32(SHA-256(Account Resource URL)[0:9]) || "._acme-challenge" + "_" || base32(SHA-256()[0:9]) || "._acme-" || ||"-challenge" - SHA-256 is the SHA hashing operation defined in {{!RFC6234}} - `[0:9]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA256 operation - base32 is the operation defined in {{!RFC4648}} - - Account Resource URL is defined in {{!RFC8555, Section 7.3}} as the value in the `Location` header field + - ACCOUNT_RESOURCE_URL is defined in {{!RFC8555, Section 7.3}} as the value in the `Location` header field + - SCOPE is + - "host" if the associated authorization applies only to the specific host name and no labels beneath it + - "wildcard" if the associated authorization is for a wildcard domain and contains the `wildcard` field set to true ({{?RFC8555, Section 7.1.4}}) + - "domain" if the authorization is for both the host and all subdomains by containing the `subdomainAuthAllowed` field set to true ({{?RFC9444, Section 4.1}}). - The `"||"` operator indicates concatenation of strings - Provision a DNS `TXT` record with the base64url digest value under the constructed domain validation name @@ -169,7 +174,7 @@ On receiving a response, the server constructs and stores the key authorization To validate the `dns-account-01` challenge, the server performs the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization -- Compute the validation domain name with the account URL of the ACME account requesting validation +- Compute the validation domain name with the account URL of the ACME account requesting validation and the associated authorization - Query for `TXT` records for the validation domain name - Verify that the contents of one of the `TXT` records match the digest value @@ -191,9 +196,9 @@ If this change occurs, the existing long-term `CNAME` records created by all acc # Security Considerations -This challenge follows the general recommendations set out in "Domain Control Validation using DNS" {{I-D.draft-ietf-dnsop-domain-verification-techniques}} for supporting multiple intermediates within the context of {{!RFC8555}}. `dns-account-01` does not attempt to introduce a "scope of validation" to the identifier for simplicity, consistency with `dns-01`, and the fact that validations can be scoped effectively via CAA records in its primary use case, the Web PKI {{?RFC8657}}. +This challenge follows the recommendations set out in "Domain Control Validation using DNS" {{I-D.draft-ietf-dnsop-domain-verification-techniques}} for supporting multiple intermediates within the context of {{!RFC8555}}. -`dns-account-01` only differs from `dns-01` in the addition of the left-most label so 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. +`dns-account-01` differs from `dns-01` in the both the addition of the left-most label and that challenges are scoped to the particular name being validated without relying upon CAA. However, 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. In terms of the construction of the label prepended to the domain name, there is no need for a cryptographic hash. The purpose of that is to create a long-lived and statistically distinctive record of minimal size. SHA-256 was picked due to its broad adoption, hardware support, and existing need in implementations that would likely support `dns-account-01`. From 399a19fd1730bf3b1a0847a0c963058d66b210ee Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 17:39:20 -0500 Subject: [PATCH 09/43] Specify how the KID value should be used --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index e496ca5..98aa883 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -192,7 +192,7 @@ If the server is unable to find a `TXT` record for the validation domain name, i As this challenge creates strong dependency on the `kid` account identifier, the server SHOULD ensure that the account identifier is not changed during the lifetime of the account. -If this change occurs, the existing long-term `CNAME` records created by all account holders will no longer be valid. The clients will not be able to issue certificates automatically moving forward. +An ACME server may have multiple `kid` values associated with a given ACME account. In such cases, the server MUST use the `kid` value that was used in the POST request to validate the challenge. # Security Considerations From 9e0d3f27f269fd304ab967c3cf0f79da3ae72200 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 17:51:17 -0500 Subject: [PATCH 10/43] Basic introduction of dns-02 --- draft-ietf-acme-dns-account-01.mkd | 78 ++++++++++++++++++++++++++++-- 1 file changed, 75 insertions(+), 3 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 98aa883..37af77e 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -106,6 +106,78 @@ makes adopting and using this challenge an opt-in process. {::boilerplate bcp14-tagged} +# DNS-02 Challenge + +When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific validation domain name. + +* type (required, string): The string "dns-02". +* token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See {{!RFC4086}} for additional information on additional requirements for secure randomness. + +~~~ +{ + "type": "dns-02", + "url": "https://example.com/acme/chall/i00MGYwLWIx", + "status": "pending", + "token": "ODE4OWY4NTktYjhmYS00YmY1LTk5MDgtZTFjYTZmNjZlYTUx" +} +~~~ + +A client can fulfill this challenge by performing the following steps: + +- Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key +- Compute the SHA-256 digest {{FIPS180-4}} of the key authorization +- Construct the validation domain name by specifying the scope for the domain name being validated: + + ._acme-" || ||"-challenge" + + - SCOPE is + - "host" if the associated authorization applies only to the specific host name and no labels beneath it + - "wildcard" if the associated authorization is for a wildcard domain and contains the `wildcard` field set to true ({{?RFC8555, Section 7.1.4}}) + - "domain" if the authorization is for both the host and all subdomains by containing the `subdomainAuthAllowed` field set to true ({{?RFC9444, Section 4.1}}). + - The `"||"` operator indicates concatenation of strings + +- Provision a DNS `TXT` record with the base64url digest value under the constructed domain validation name + +For example, if the domain name being validated is the wildcard of `*.example.org` then the client would provision the following DNS record: + +~~~ +_acme-wildcard-challenge.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" +~~~ + +(In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) + +Respond to the ACME server with an empty object ({}) to acknowledge that the challenge can be validated by the server + +~~~ +POST /acme/chall/Rg5dV14Gh1Q +Host: example.com +Content-Type: application/jose+json + +{ + "protected": base64url({ + "alg": "ES256", + "kid": "https://example.com/acme/acct/evOfKhNU60wg", + "nonce": "SS2sSl1PtspvFZ08kNtzKd", + "url": "https://example.com/acme/chall/Rg5dV14Gh1Q" + }), + "payload": base64url({}), + "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" +} +~~~ + +On receiving a response, the server constructs and stores the key authorization from the challenge `token` value. + +To validate the `dns-02` challenge, the server performs the following steps: + +- Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization +- Compute the validation domain name with the scope of the associated authorization similiar to the client +- Query for `TXT` records for the validation domain name +- Verify that the contents of one of the `TXT` records match the digest value + +If all the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the server MUST fail the validation and mark the challenge as invalid. + +The client SHOULD de-provision the resource record(s) provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid". + # DNS-ACCOUNT-01 Challenge When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific validation domain name. @@ -142,10 +214,10 @@ A client can fulfill this challenge by performing the following steps: - Provision a DNS `TXT` record with the base64url digest value under the constructed domain validation name -For example, if the domain name being validated is `www.example.org`, and the account URL of `https://example.com/acme/acct/ExampleAccount` then the client would provision the following DNS record: +For example, if the domain name being validated is `*.example.org`, and the account URL of `https://example.com/acme/acct/ExampleAccount` then the client would provision the following DNS record: ~~~ -_ujmmovf2vn55tgye._acme-challenge.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" +_ujmmovf2vn55tgye._acme-wildcard-challenge.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" ~~~ (In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) @@ -174,7 +246,7 @@ On receiving a response, the server constructs and stores the key authorization To validate the `dns-account-01` challenge, the server performs the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization -- Compute the validation domain name with the account URL of the ACME account requesting validation and the associated authorization +- Compute the validation domain name with the account URL of the ACME account requesting validation and the associated authorization similar to the client - Query for `TXT` records for the validation domain name - Verify that the contents of one of the `TXT` records match the digest value From f7b1fa9772f6c675d4740ddf2bb11e3a5c62b6d7 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 17:52:30 -0500 Subject: [PATCH 11/43] Rename docname --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 37af77e..6df0ac4 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -3,7 +3,7 @@ title: "Automated Certificate Management Environment (ACME) DNS Labeled With ACM abbrev: "ACME-DNS-CHALLENGE" category: std -docname: draft-ietf-acme-dns-account-challenge-00 +docname: draft-ietf-acme-scoped-dns-challenge v: 3 area: Security workgroup: Automated Certificate Management Environment From 4eadab4ed6948bfb91e9d78179a1208c1969822c Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 18:02:57 -0500 Subject: [PATCH 12/43] Rewrite introduction --- draft-ietf-acme-dns-account-01.mkd | 45 ++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 6df0ac4..dff77ad 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -63,14 +63,22 @@ systems or environments to handle challenge-solving for a single domain. The `dns-01` challenge specified in section 8.4 of {{!RFC8555}} requires that ACME clients validate the domain under the `_acme-challenge` label for the -`TXT` record. This unique label creates an impediment limiting the number of -other entities domain validation can be delegated to. - -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 +`TXT` record. This label creates several limiations in domain validation. + +First, the `_acme-challenge` label, does not specify if the authorization is +intended for a specific host, a wildcard domain, or a domain and all of its +subdomains. This means that in practice, when validating a specific dns name +with DNS-01, the ACME server is effectively validating that dns name, and all +of its subdomains. This lack of scoping has security implications for the domain. + +Furthermore, since this label is unique to the domain, it creates an impediment +limiting the number of other entities domain vlaidation can be delegated to. + +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. Due to the uniqueness of the `_acme-challenge` label, operators today have to @@ -78,11 +86,17 @@ pick a single ACME challenge solver for their domain name, and then add a `CNAME` record to this infrastructure. A domain name can only have one `CNAME` in DNS. -This document specifies a new challenge type, `dns-account-01`. This challenge -leverages the ACME Account Resource URL to present an account-unique stable -challenge to an ACME server. This challenge allows any domain name to delegate -its domain validation to more than one service through ACME account-unique DNS -records. +This document specifies two new challenge types. `dns-02` and `dns-account-01`. + +The `dns-02` challenge adds onto `dns-01` by introducing a scoping mechanism +to the domain validation 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. + +The `dns-account-01` leverages the ACME Account Resource URL to present an +account-unique stable challenge to an ACME server. This challenge allows any +domain name to delegate its domain validation to more than one service through +ACME account-unique DNS records. As now multiple labels can be used to prove domain control, and they depend on the ACME account, any number of them can be generated in advance, and then all @@ -97,11 +111,14 @@ In particular, unlike `dns-01`, each validation is scoped to the particular label being validated. This RFC does not intend to deprecate the `dns-01` challenge specified in -{{!RFC8555}}. Since this new challenge does not modify or build on any +{{!RFC8555}}. Since these new challenge does not modify or build on 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 this challenge an opt-in process. +Eventually, a domain operator may choose to not allow the use of `dns-01` through +CAA records. + # Conventions and Definitions {::boilerplate bcp14-tagged} From 705bb5f6ffc826b31f7be2dc5f75e3fa82eea6ee Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:25:40 -0500 Subject: [PATCH 13/43] More IANA things, and grammar changes --- draft-ietf-acme-dns-account-01.mkd | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index dff77ad..0b87d9d 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -65,11 +65,13 @@ The `dns-01` challenge specified in section 8.4 of {{!RFC8555}} requires that ACME clients validate the domain under the `_acme-challenge` label for the `TXT` record. This label creates several limiations in domain validation. -First, the `_acme-challenge` label, does not specify if the authorization is +First, the `_acme-challenge` label does not specify if the authorization is intended for a specific host, a wildcard domain, or a domain and all of its -subdomains. This means that in practice, when validating a specific dns name -with DNS-01, the ACME server is effectively validating that dns name, and all -of its subdomains. This lack of scoping has security implications for the domain. +subdomains. Consequently, when validating a specific dns name with the DNS-01 +challenge, the ACME server might be interpreted as validating control over +that dns name, and potentially its subdomains. This broad validation scope can +have security implications, such as erroneously assuming control over the dns +name and all of its subdomains. Furthermore, since this label is unique to the domain, it creates an impediment limiting the number of other entities domain vlaidation can be delegated to. @@ -297,13 +299,18 @@ The first 10 bytes were picked as a tradeoff: the value needs to be short enough ## ACME Validation Method -The "ACME Validation Methods" registry is to be updated to include the following entry: +The "ACME Validation Methods" registry is to be updated to include the following entries: ~~~ label: dns-account-01 identifier-type: dns ACME: Y Reference: This document + +label: dns-02 +identifier-type: dns +ACME: Y +Reference: This document ~~~ From 488c8e8069e741b0f4a61cd634c39b6e6a7942be Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:31:39 -0500 Subject: [PATCH 14/43] wording --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index cddd811..6447a6d 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -118,7 +118,7 @@ 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 this challenge an opt-in process. -Eventually, a domain operator may choose to not allow the use of `dns-01` through +Eventually, a domain operator may choose to prohibit the use of `dns-01` through CAA records. # Conventions and Definitions From cc02509a88c91c7528d6d3216796fb1f6141f3de Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:34:06 -0500 Subject: [PATCH 15/43] Spelling --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 6447a6d..2cca0b3 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -74,7 +74,7 @@ have security implications, such as erroneously assuming control over the dns name and all of its subdomains. Furthermore, since this label is unique to the domain, it creates an impediment -limiting the number of other entities domain vlaidation can be delegated to. +limiting the number of other entities domain validation can be delegated to. In multi-region deployments, where separate availability zones serve the same content, and dependencies across them are avoided, operators need From 19faa977ef0b4fabaf65d17b9995cab6b8e57fae Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:35:13 -0500 Subject: [PATCH 16/43] draft-ietf-acme-scoped-dns-challenge-00 -> draft-ietf-acme-scoped-dns-challenges-00 --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 2cca0b3..762436d 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -3,7 +3,7 @@ title: "Automated Certificate Management Environment (ACME) DNS Labeled With ACM abbrev: "ACME-DNS-CHALLENGE" category: std -docname: draft-ietf-acme-scoped-dns-challenge-00 +docname: draft-ietf-acme-scoped-dns-challenges-00 v: 3 area: Security workgroup: Automated Certificate Management Environment From 573b8d6cddf9707831448cf12fbe9c2a5360457e Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:36:15 -0500 Subject: [PATCH 17/43] Include errors section --- draft-ietf-acme-dns-account-01.mkd | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 762436d..71b867c 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -197,6 +197,10 @@ If all the above verifications succeed, then the validation is successful. If no The client SHOULD de-provision the resource record(s) provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid". +## Errors + +The server SHOULD follow the guidelines set in {{!RFC8555, Section 6.7}} for error conditions that occur during challenge validation. + # DNS-ACCOUNT-01 Challenge When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific validation domain name. From 1a7e22b5c8028b72b37f4f1083daff8c21b0636c Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:43:31 -0500 Subject: [PATCH 18/43] Make paragraph easier to understand --- draft-ietf-acme-dns-account-01.mkd | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 71b867c..ad026a4 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -95,17 +95,19 @@ to the domain validation 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. -The `dns-account-01` leverages the ACME Account Resource URL to present an -account-unique stable challenge to an ACME server. This challenge allows any +The `dns-account-01` challenge leverages the ACME Account Resource URL to present +an account-unique stable challenge to an ACME server. This challenge allows any domain name to delegate its domain validation to more than one service through ACME account-unique DNS records. -As now multiple labels can be used to prove domain control, and they depend on -the ACME account, any number of them can be generated in advance, and then all -required `CNAME` records can be created statically. The dynamic part of the -label depends on the ACME account and not the account key, to allow for -seamless account key rollover without the label changing. This ensures very -long-lived labels, without any security considerations. +With this new challenge, domain validation of the same DNS name can be done through +different validation labels. Since these validation labels will depend on the ACME +account KID, any number of them can be generated in advance. This allows all +required `CNAME` records for domain validation delegation to be constructed statically. + +To allow for seamless account key rollover without the label changing, the dynamic +part of the label depends on the ACME account and not the account key. This allows +for long-lived labels, without the security considerations of keeping the account key static. Finally, this work follows all recommendations set forth in "Domain Control Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. From 9e80b67a9ee1fed20f15c42d7f49c10539375731 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:48:59 -0500 Subject: [PATCH 19/43] More wording changes --- draft-ietf-acme-dns-account-01.mkd | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index ad026a4..750d537 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -115,10 +115,10 @@ In particular, unlike `dns-01`, each validation is scoped to the particular label being validated. This RFC does not intend to deprecate the `dns-01` challenge specified in -{{!RFC8555}}. Since these new challenge does not modify or build on 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 this challenge an opt-in process. +{{!RFC8555}}. Since these new challenges do not modify any pre-existing challenges, +the ability to complete the `dns-02` or `dns-account-01` challenge requires ACME server +operators to deploy new changes to their codebase. This makes adopting and using this +challenge an opt-in process. Eventually, a domain operator may choose to prohibit the use of `dns-01` through CAA records. From 67073ce7d635c3ce79ef6943566ab79e4bfdbd04 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 20:54:15 -0500 Subject: [PATCH 20/43] Move IANA stuff around --- draft-ietf-acme-dns-account-01.mkd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 750d537..3c326e8 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -308,12 +308,12 @@ The first 10 bytes were picked as a tradeoff: the value needs to be short enough The "ACME Validation Methods" registry is to be updated to include the following entries: ~~~ -label: dns-account-01 +label: dns-02 identifier-type: dns ACME: Y Reference: This document -label: dns-02 +label: dns-account-01 identifier-type: dns ACME: Y Reference: This document From 44103a21fdbe6a02a4b82b3a39aba549b035fbd4 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Tue, 6 Feb 2024 21:04:06 -0500 Subject: [PATCH 21/43] Update example --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 3c326e8..fcd509b 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -242,7 +242,7 @@ A client can fulfill this challenge by performing the following steps: For example, if the domain name being validated is `*.example.org`, and the account URL of `https://example.com/acme/acct/ExampleAccount` then the client would provision the following DNS record: ~~~ -_ujmmovf2vn55tgye._acme-wildcard-challenge.www.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" +_ujmmovf2vn55tgye._acme-wildcard-challenge.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" ~~~ (In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) From d70c0dbea6c76c3e9c663db52b65a71d47a73b4d Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 11:05:16 -0500 Subject: [PATCH 22/43] dns name -> DNS name --- draft-ietf-acme-dns-account-01.mkd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index fcd509b..16b9da8 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -67,9 +67,9 @@ ACME clients validate the domain under the `_acme-challenge` label for the First, the `_acme-challenge` label does not specify if the authorization is intended for a specific host, a wildcard domain, or a domain and all of its -subdomains. Consequently, when validating a specific dns name with the DNS-01 +subdomains. Consequently, when validating a specific DNS name with the DNS-01 challenge, the ACME server might be interpreted as validating control over -that dns name, and potentially its subdomains. This broad validation scope can +that DNS name, and potentially its subdomains. This broad validation scope can have security implications, such as erroneously assuming control over the dns name and all of its subdomains. From c74f7095b1fae36889e4c1afc98c672471c02110 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 11:06:12 -0500 Subject: [PATCH 23/43] Reword label uniqueness --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 16b9da8..9f970e9 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -73,7 +73,7 @@ that DNS name, and potentially its subdomains. This broad validation scope can have security implications, such as erroneously assuming control over the dns name and all of its subdomains. -Furthermore, since this label is unique to the domain, it creates an impediment +Furthermore, since each domain only has a single authorization label, it creates an impediment limiting the number of other entities domain validation can be delegated to. In multi-region deployments, where separate availability zones From 90edc64aef9b597f5209c4be26c948888840b748 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 11:07:29 -0500 Subject: [PATCH 24/43] Remove sentence about scoping in the intro --- draft-ietf-acme-dns-account-01.mkd | 2 -- 1 file changed, 2 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 9f970e9..0fe0a30 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -111,8 +111,6 @@ for long-lived labels, without the security considerations of keeping the accoun Finally, this work follows all recommendations set forth in "Domain Control Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. -In particular, unlike `dns-01`, each validation is scoped to the particular -label being validated. 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, From 552ea745677a64dbe75eed65349851015c2f4519 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 11:19:09 -0500 Subject: [PATCH 25/43] Reorganize the document to be a bit more clear what we're talking about --- draft-ietf-acme-dns-account-01.mkd | 37 +++++++++++++++--------------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 0fe0a30..7724d48 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -90,11 +90,24 @@ in DNS. This document specifies two new challenge types. `dns-02` and `dns-account-01`. +This work follows all recommendations set forth in "Domain Control +Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. + +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-02` or `dns-account-01` challenge requires ACME server +operators to deploy new changes to their codebase. This makes adopting and using this +challenge an opt-in process. + +## DNS-02 + The `dns-02` challenge adds onto `dns-01` by introducing a scoping mechanism to the domain validation 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. +## DNS-01 + The `dns-account-01` challenge leverages the ACME Account Resource URL to present an account-unique stable challenge to an ACME server. This challenge allows any domain name to delegate its domain validation to more than one service through @@ -105,22 +118,6 @@ different validation labels. Since these validation labels will depend on the AC account KID, any number of them can be generated in advance. This allows all required `CNAME` records for domain validation delegation to be constructed statically. -To allow for seamless account key rollover without the label changing, the dynamic -part of the label depends on the ACME account and not the account key. This allows -for long-lived labels, without the security considerations of keeping the account key static. - -Finally, this work follows all recommendations set forth in "Domain Control -Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. - -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-02` or `dns-account-01` challenge requires ACME server -operators to deploy new changes to their codebase. This makes adopting and using this -challenge an opt-in process. - -Eventually, a domain operator may choose to prohibit the use of `dns-01` through -CAA records. - # Conventions and Definitions {::boilerplate bcp14-tagged} @@ -291,9 +288,13 @@ An ACME server may have multiple `kid` values associated with a given ACME accou # Security Considerations -This challenge follows the recommendations set out in "Domain Control Validation using DNS" {{I-D.draft-ietf-dnsop-domain-verification-techniques}} for supporting multiple intermediates within the context of {{!RFC8555}}. +These challenges follows the recommendations set out in "Domain Control Validation using DNS" {{I-D.draft-ietf-dnsop-domain-verification-techniques}} for supporting multiple intermediates within the context of {{!RFC8555}}. + +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`. + +## DNS-ACCOUNT-01 -`dns-account-01` differs from `dns-01` in the both the addition of the left-most label and that challenges are scoped to the particular name being validated without relying upon CAA. However, 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. +To allow for seamless account key rollover without the label changing, the dynamic part of the label depends on the ACME account and not the account key. This allows for long-lived labels, without the security considerations of keeping the account key static. In terms of the construction of the label prepended to the domain name, there is no need for a cryptographic hash. The purpose of that is to create a long-lived and statistically distinctive record of minimal size. SHA-256 was picked due to its broad adoption, hardware support, and existing need in implementations that would likely support `dns-account-01`. From 431eab8495e8f340f5870a9436251f1025c63d21 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 11:21:27 -0500 Subject: [PATCH 26/43] Let's try this --- draft-ietf-acme-dns-account-01.mkd | 52 +++++++++++++++--------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 7724d48..5db9d34 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -234,32 +234,32 @@ A client can fulfill this challenge by performing the following steps: - Provision a DNS `TXT` record with the base64url digest value under the constructed domain validation name -For example, if the domain name being validated is `*.example.org`, and the account URL of `https://example.com/acme/acct/ExampleAccount` then the client would provision the following DNS record: - -~~~ -_ujmmovf2vn55tgye._acme-wildcard-challenge.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" -~~~ - -(In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) - -Respond to the ACME server with an empty object ({}) to acknowledge that the challenge can be validated by the server - -~~~ -POST /acme/chall/Rg5dV14Gh1Q -Host: example.com -Content-Type: application/jose+json - -{ - "protected": base64url({ - "alg": "ES256", - "kid": "https://example.com/acme/acct/evOfKhNU60wg", - "nonce": "SS2sSl1PtspvFZ08kNtzKd", - "url": "https://example.com/acme/chall/Rg5dV14Gh1Q" - }), - "payload": base64url({}), - "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" -} -~~~ + For example, if the domain name being validated is `*.example.org`, and the account URL of `https://example.com/acme/acct/ExampleAccount` then the client would provision the following DNS record: + + ~~~ + _ujmmovf2vn55tgye._acme-wildcard-challenge.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" + ~~~ + + (In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) + +- Respond to the ACME server with an empty object ({}) to acknowledge that the challenge can be validated by the server + + ~~~ + POST /acme/chall/Rg5dV14Gh1Q + Host: example.com + Content-Type: application/jose+json + + { + "protected": base64url({ + "alg": "ES256", + "kid": "https://example.com/acme/acct/evOfKhNU60wg", + "nonce": "SS2sSl1PtspvFZ08kNtzKd", + "url": "https://example.com/acme/chall/Rg5dV14Gh1Q" + }), + "payload": base64url({}), + "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" + } + ~~~ On receiving a response, the server constructs and stores the key authorization from the challenge `token` value and the current client account key. From b3e3d23d7baa95e1ddac82abd5f80e1010a4f8ae Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 17:27:45 +0000 Subject: [PATCH 27/43] Formatting --- draft-ietf-acme-dns-account-01.mkd | 42 +++++++++++++++--------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 5db9d34..e60cf3f 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -154,32 +154,32 @@ A client can fulfill this challenge by performing the following steps: - Provision a DNS `TXT` record with the base64url digest value under the constructed domain validation name -For example, if the domain name being validated is the wildcard of `*.example.org` then the client would provision the following DNS record: + For example, if the domain name being validated is the wildcard of `*.example.org` then the client would provision the following DNS record: -~~~ -_acme-wildcard-challenge.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" -~~~ + ~~~ + _acme-wildcard-challenge.example.org 300 IN TXT "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" + ~~~ -(In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) + (In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) -Respond to the ACME server with an empty object ({}) to acknowledge that the challenge can be validated by the server +- Respond to the ACME server with an empty object ({}) to acknowledge that the challenge can be validated by the server -~~~ -POST /acme/chall/Rg5dV14Gh1Q -Host: example.com -Content-Type: application/jose+json + ~~~ + POST /acme/chall/Rg5dV14Gh1Q + Host: example.com + Content-Type: application/jose+json -{ - "protected": base64url({ - "alg": "ES256", - "kid": "https://example.com/acme/acct/evOfKhNU60wg", - "nonce": "SS2sSl1PtspvFZ08kNtzKd", - "url": "https://example.com/acme/chall/Rg5dV14Gh1Q" - }), - "payload": base64url({}), - "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" -} -~~~ + { + "protected": base64url({ + "alg": "ES256", + "kid": "https://example.com/acme/acct/evOfKhNU60wg", + "nonce": "SS2sSl1PtspvFZ08kNtzKd", + "url": "https://example.com/acme/chall/Rg5dV14Gh1Q" + }), + "payload": base64url({}), + "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" + } + ~~~ On receiving a response, the server constructs and stores the key authorization from the challenge `token` value. From cf8cc3333e52531c4a8689957640e6788fd15b8c Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 17:34:08 +0000 Subject: [PATCH 28/43] Reword the introduction --- draft-ietf-acme-dns-account-01.mkd | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index e60cf3f..b532020 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -75,6 +75,9 @@ name and all of its subdomains. Furthermore, since each domain only has a single authorization label, it creates an impediment limiting the number of other entities domain validation can be delegated to. +Delegating authorization to an entity requires the use of CNAME records, which can only used once +per DNS name (or in this case, once per authorization label). This limitation requires that +operators to pick a single ACME challenge solver for their domain name. In multi-region deployments, where separate availability zones serve the same content, and dependencies across them are avoided, operators need @@ -83,11 +86,6 @@ 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. -Due to the uniqueness of the `_acme-challenge` label, operators today have to -pick a single ACME challenge solver for their domain name, and then add a -`CNAME` record to this infrastructure. A domain name can only have one `CNAME` -in DNS. - This document specifies two new challenge types. `dns-02` and `dns-account-01`. This work follows all recommendations set forth in "Domain Control From 909e5c8abb13e1c6296d0067c9c05511d85a4923 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 17:42:42 +0000 Subject: [PATCH 29/43] Cite CAA --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index b532020..55ff52e 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -288,7 +288,7 @@ An ACME server may have multiple `kid` values associated with a given ACME accou These challenges follows the recommendations set out in "Domain Control Validation using DNS" {{I-D.draft-ietf-dnsop-domain-verification-techniques}} for supporting multiple intermediates within the context of {{!RFC8555}}. -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`. +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}}). ## DNS-ACCOUNT-01 From ef643f1ebfc83eceafa32b8c8c5432b711373655 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 17:43:28 +0000 Subject: [PATCH 30/43] s/validation domain name/authorization domain name --- draft-ietf-acme-dns-account-01.mkd | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 55ff52e..2aa5b7b 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -122,7 +122,7 @@ required `CNAME` records for domain validation delegation to be constructed stat # DNS-02 Challenge -When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific validation domain name. +When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific authorization domain name. * type (required, string): The string "dns-02". * token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See {{!RFC4086}} for additional information on additional requirements for secure randomness. @@ -140,7 +140,7 @@ A client can fulfill this challenge by performing the following steps: - Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization -- Construct the validation domain name by specifying the scope for the domain name being validated: +- Construct the authorization domain name by specifying the scope for the domain name being validated: ._acme-" || ||"-challenge" @@ -184,8 +184,8 @@ On receiving a response, the server constructs and stores the key authorization To validate the `dns-02` challenge, the server performs the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization -- Compute the validation domain name with the scope of the associated authorization similiar to the client -- Query for `TXT` records for the validation domain name +- Compute the authorization domain name with the scope of the associated authorization similiar to the client +- Query for `TXT` records for the authorization domain name - Verify that the contents of one of the `TXT` records match the digest value If all the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the server MUST fail the validation and mark the challenge as invalid. @@ -198,7 +198,7 @@ The server SHOULD follow the guidelines set in {{!RFC8555, Section 6.7}} for err # DNS-ACCOUNT-01 Challenge -When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific validation domain name. +When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific authorization domain name. * type (required, string): The string "dns-account-01". * token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See {{!RFC4086}} for additional information on additional requirements for secure randomness. @@ -216,7 +216,7 @@ A client can fulfill this challenge by performing the following steps: - Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization -- Construct the validation domain name by prepending the following label to the domain name being validated: +- Construct the authorization domain name by prepending the following label to the domain name being validated: "_" || base32(SHA-256()[0:9]) || "._acme-" || ||"-challenge" @@ -264,8 +264,8 @@ On receiving a response, the server constructs and stores the key authorization To validate the `dns-account-01` challenge, the server performs the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization -- Compute the validation domain name with the account URL of the ACME account requesting validation and the associated authorization similar to the client -- Query for `TXT` records for the validation domain name +- Compute the authorization domain name with the account URL of the ACME account requesting validation and the associated authorization similar to the client +- Query for `TXT` records for the authorization domain name - Verify that the contents of one of the `TXT` records match the digest value If all the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the server MUST fail the validation and mark the challenge as invalid. @@ -276,7 +276,7 @@ The client SHOULD de-provision the resource record(s) provisioned for this chall The server SHOULD follow the guidelines set in {{!RFC8555, Section 6.7}} for error conditions that occur during challenge validation. -If the server is unable to find a `TXT` record for the validation domain name, it SHOULD include the account URL it used to construct the validation domain name in the problem document. Clients MUST NOT use or rely on the presence of this field to construct the validation domain name. +If the server is unable to find a `TXT` record for the authorization domain name, it SHOULD include the account URL it used to construct the authorization domain name in the problem document. Clients MUST NOT use or rely on the presence of this field to construct the authorization domain name. ## Implementation Considerations From d42963ef935c128813cc41e7820c40d76c80d9ab Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 17:45:16 +0000 Subject: [PATCH 31/43] Reword SHA-256 --- draft-ietf-acme-dns-account-01.mkd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 2aa5b7b..dac1751 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -221,7 +221,7 @@ A client can fulfill this challenge by performing the following steps: "_" || base32(SHA-256()[0:9]) || "._acme-" || ||"-challenge" - SHA-256 is the SHA hashing operation defined in {{!RFC6234}} - - `[0:9]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA256 operation + - `[0:9]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA-256 operation - base32 is the operation defined in {{!RFC4648}} - ACCOUNT_RESOURCE_URL is defined in {{!RFC8555, Section 7.3}} as the value in the `Location` header field - SCOPE is @@ -294,7 +294,7 @@ In both `dns-account-01` and `dns-02`, the same security considerations apply fo To allow for seamless account key rollover without the label changing, the dynamic part of the label depends on the ACME account and not the account key. This allows for long-lived labels, without the security considerations of keeping the account key static. -In terms of the construction of the label prepended to the domain name, there is no need for a cryptographic hash. The purpose of that is to create a long-lived and statistically distinctive record of minimal size. SHA-256 was picked due to its broad adoption, hardware support, and existing need in implementations that would likely support `dns-account-01`. +In terms of the construction of the label prepended to the domain name, there is no need for a cryptographic hash. The purpose of that is to create a long-lived and statistically distinctive record of minimal size. SHA-256 was picked due to it already being used for existing `dns-01` challenges ({{!RFC8555, Section 8.1}}). The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS record and response size, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. From 914111a35c42ca378e1f47c18b1cedb960a13ea7 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 18:45:12 +0000 Subject: [PATCH 32/43] Fix introduction --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index dac1751..d464ac2 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -104,7 +104,7 @@ to the domain validation 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. -## DNS-01 +## DNS-ACCOUNT-01 The `dns-account-01` challenge leverages the ACME Account Resource URL to present an account-unique stable challenge to an ACME server. This challenge allows any From f803417da2b5e1c6ee1969c55c5425b566f5c55f Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 18:55:21 +0000 Subject: [PATCH 33/43] Add build task --- .devcontainer/devcontainer.json | 9 ++++++++- .vscode/tasks.json | 14 ++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) create mode 100644 .vscode/tasks.json diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index 5a5eaa1..8b3c9cc 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -6,5 +6,12 @@ "VARIANT": "ubuntu-22.04" } }, - "remoteUser": "vscode" + "remoteUser": "vscode", + "customizations": { + "vscode": { + "extensions": [ + "ms-vscode.live-server" + ] + } + } } diff --git a/.vscode/tasks.json b/.vscode/tasks.json new file mode 100644 index 0000000..d0d0732 --- /dev/null +++ b/.vscode/tasks.json @@ -0,0 +1,14 @@ +{ + "version": "2.0.0", + "tasks": [ + { + "label": "Build", + "type": "shell", + "command": "/usr/local/bin/kramdown-rfc2629 --v3 draft-ietf-acme-dns-account-01.mkd > docs/draft.xml && xml2rfc --text --html --v3 docs/draft.xml", + "group": { + "kind": "build", + "isDefault": true + } + } + ] +} From 967b7d27a30f447c7acce3c12c9255e87efcd851 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Wed, 7 Feb 2024 18:57:17 +0000 Subject: [PATCH 34/43] Typo --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index d464ac2..954cb9c 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -142,7 +142,7 @@ A client can fulfill this challenge by performing the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization - Construct the authorization domain name by specifying the scope for the domain name being validated: - ._acme-" || ||"-challenge" + "_acme-" || ||"-challenge" - SCOPE is - "host" if the associated authorization applies only to the specific host name and no labels beneath it From d8eec9c070013406a0ebedd0e190ee01b3a3e3c8 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Thu, 8 Feb 2024 18:12:00 -0500 Subject: [PATCH 35/43] Apply suggestions from code review Co-authored-by: Aaron Gable --- draft-ietf-acme-dns-account-01.mkd | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 954cb9c..53f5af7 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -86,7 +86,7 @@ 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`. +This document specifies two new challenge types. `dns-02` and `dns-account-01`, which aim to address these deficiencies. This work follows all recommendations set forth in "Domain Control Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. @@ -94,8 +94,8 @@ Validation using DNS" [I-D.draft-ietf-dnsop-domain-verification-techniques]. 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-02` or `dns-account-01` challenge requires ACME server -operators to deploy new changes to their codebase. This makes adopting and using this -challenge an opt-in process. +operators to deploy new changes to their codebase. This makes adopting and using these +challenges an opt-in process. ## DNS-02 @@ -216,7 +216,7 @@ A client can fulfill this challenge by performing the following steps: - Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization -- Construct the authorization domain name by prepending the following label to the domain name being validated: +- Construct the authorization domain name by prepending the following two labels to the domain name being validated: "_" || base32(SHA-256()[0:9]) || "._acme-" || ||"-challenge" @@ -282,7 +282,7 @@ If the server is unable to find a `TXT` record for the authorization domain name As this challenge creates strong dependency on the `kid` account identifier, the server SHOULD ensure that the account identifier is not changed during the lifetime of the account. -An ACME server may have multiple `kid` values associated with a given ACME account. In such cases, the server MUST use the `kid` value that was used in the POST request to validate the challenge. +An ACME server may have multiple `kid` values associated with a given ACME account. In such cases, the server MUST use the `kid` value that was used in the POST request to the challenge URL. # Security Considerations From d0e853fecfdf510574881fb33ff7826398832d96 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Thu, 8 Feb 2024 23:13:42 +0000 Subject: [PATCH 36/43] Change [0:9] to [0:10], remove kid reference in implementation consideration, reference kid in introduction --- draft-ietf-acme-dns-account-01.mkd | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 53f5af7..ffe29c6 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -113,8 +113,9 @@ ACME account-unique DNS records. With this new challenge, domain validation of the same DNS name can be done through different validation labels. Since these validation labels will depend on the ACME -account KID, any number of them can be generated in advance. This allows all -required `CNAME` records for domain validation delegation to be constructed statically. +account KID ({{!RFC8555, Section 6.2}}), any number of them can be generated in advance. +This allows all required `CNAME` records for domain validation delegation to be constructed +statically. # Conventions and Definitions @@ -218,10 +219,10 @@ A client can fulfill this challenge by performing the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization - Construct the authorization domain name by prepending the following two labels to the domain name being validated: - "_" || base32(SHA-256()[0:9]) || "._acme-" || ||"-challenge" + "_" || base32(SHA-256()[0:10]) || "._acme-" || ||"-challenge" - SHA-256 is the SHA hashing operation defined in {{!RFC6234}} - - `[0:9]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA-256 operation + - `[0:10]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA-256 operation - base32 is the operation defined in {{!RFC4648}} - ACCOUNT_RESOURCE_URL is defined in {{!RFC8555, Section 7.3}} as the value in the `Location` header field - SCOPE is @@ -282,8 +283,6 @@ If the server is unable to find a `TXT` record for the authorization domain name As this challenge creates strong dependency on the `kid` account identifier, the server SHOULD ensure that the account identifier is not changed during the lifetime of the account. -An ACME server may have multiple `kid` values associated with a given ACME account. In such cases, the server MUST use the `kid` value that was used in the POST request to the challenge URL. - # Security Considerations These challenges follows the recommendations set out in "Domain Control Validation using DNS" {{I-D.draft-ietf-dnsop-domain-verification-techniques}} for supporting multiple intermediates within the context of {{!RFC8555}}. From 3f62aa7fb826c262723af42e2f1ad21d76a0c6a0 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Thu, 8 Feb 2024 23:21:09 +0000 Subject: [PATCH 37/43] validation domain name -> authorization domain name --- draft-ietf-acme-dns-account-01.mkd | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index ffe29c6..1b4ec69 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -123,7 +123,7 @@ statically. # DNS-02 Challenge -When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific authorization domain name. +When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific validation domain name. * type (required, string): The string "dns-02". * token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See {{!RFC4086}} for additional information on additional requirements for secure randomness. @@ -141,7 +141,7 @@ A client can fulfill this challenge by performing the following steps: - Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization -- Construct the authorization domain name by specifying the scope for the domain name being validated: +- Construct the validation domain name by specifying the scope for the domain name being validated: "_acme-" || ||"-challenge" @@ -185,8 +185,8 @@ On receiving a response, the server constructs and stores the key authorization To validate the `dns-02` challenge, the server performs the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization -- Compute the authorization domain name with the scope of the associated authorization similiar to the client -- Query for `TXT` records for the authorization domain name +- Compute the validation domain name with the scope of the associated authorization similiar to the client +- Query for `TXT` records for the validation domain name - Verify that the contents of one of the `TXT` records match the digest value If all the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the server MUST fail the validation and mark the challenge as invalid. @@ -199,7 +199,7 @@ The server SHOULD follow the guidelines set in {{!RFC8555, Section 6.7}} for err # DNS-ACCOUNT-01 Challenge -When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific authorization domain name. +When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a `TXT` resource record containing a designated value for a specific validation domain name. * type (required, string): The string "dns-account-01". * token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). See {{!RFC4086}} for additional information on additional requirements for secure randomness. @@ -217,7 +217,7 @@ A client can fulfill this challenge by performing the following steps: - Construct a key authorization {{!RFC8555, Section 8.1}} from the `token` value provided in the challenge and the client's account key - Compute the SHA-256 digest {{FIPS180-4}} of the key authorization -- Construct the authorization domain name by prepending the following two labels to the domain name being validated: +- Construct the validation domain name by prepending the following two labels to the domain name being validated: "_" || base32(SHA-256()[0:10]) || "._acme-" || ||"-challenge" @@ -265,8 +265,8 @@ On receiving a response, the server constructs and stores the key authorization To validate the `dns-account-01` challenge, the server performs the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization -- Compute the authorization domain name with the account URL of the ACME account requesting validation and the associated authorization similar to the client -- Query for `TXT` records for the authorization domain name +- Compute the validation domain name with the account URL of the ACME account requesting validation and the associated authorization similar to the client +- Query for `TXT` records for the validation domain name - Verify that the contents of one of the `TXT` records match the digest value If all the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the server MUST fail the validation and mark the challenge as invalid. @@ -277,7 +277,7 @@ The client SHOULD de-provision the resource record(s) provisioned for this chall The server SHOULD follow the guidelines set in {{!RFC8555, Section 6.7}} for error conditions that occur during challenge validation. -If the server is unable to find a `TXT` record for the authorization domain name, it SHOULD include the account URL it used to construct the authorization domain name in the problem document. Clients MUST NOT use or rely on the presence of this field to construct the authorization domain name. +If the server is unable to find a `TXT` record for the validation domain name, it SHOULD include the account URL it used to construct the validation domain name in the problem document. Clients MUST NOT use or rely on the presence of this field to construct the validation domain name. ## Implementation Considerations From 7d10468b0d09f57cd818e00f0418511bd71ec523 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Thu, 8 Feb 2024 23:22:38 +0000 Subject: [PATCH 38/43] authorization label -> validation label --- draft-ietf-acme-dns-account-01.mkd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 1b4ec69..72a81d0 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -100,7 +100,7 @@ challenges an opt-in process. ## DNS-02 The `dns-02` challenge adds onto `dns-01` by introducing a scoping mechanism -to the domain validation label. This allows for the client to specify if the +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. @@ -112,7 +112,7 @@ domain name to delegate its domain validation to more than one service through ACME account-unique DNS records. With this new challenge, domain validation of the same DNS name can be done through -different validation labels. Since these validation labels will depend on the ACME +different authorization labels. Since these authorization labels will depend on the ACME account KID ({{!RFC8555, Section 6.2}}), any number of them can be generated in advance. This allows all required `CNAME` records for domain validation delegation to be constructed statically. From 4b2bcdc059d910051605e3a1e7b7aca809481ad9 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 9 Feb 2024 19:55:57 +0000 Subject: [PATCH 39/43] Rename abbrev --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 72a81d0..8b5329d 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -1,6 +1,6 @@ --- title: "Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge" -abbrev: "ACME-DNS-CHALLENGE" +abbrev: "ACME-SCOPED-DNS-CHALLENGES" category: std docname: draft-ietf-acme-scoped-dns-challenges-00 From 417aee4bc4f07c092ae9a46de757a3c5ad8d3584 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 9 Feb 2024 15:02:28 -0500 Subject: [PATCH 40/43] Apply suggestions from code review Co-authored-by: James Kasten --- draft-ietf-acme-dns-account-01.mkd | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 8b5329d..1c9836f 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -67,7 +67,7 @@ ACME clients validate the domain under the `_acme-challenge` label for the First, the `_acme-challenge` label does not specify if the authorization is intended for a specific host, a wildcard domain, or a domain and all of its -subdomains. Consequently, when validating a specific DNS name with the DNS-01 +subdomains. Consequently, domain owners who may be delegating or provisioning authorization labels for a domain must concede control over the domain and all subdomains, violating the principle of least privilege. challenge, the ACME server might be interpreted as validating control over that DNS name, and potentially its subdomains. This broad validation scope can have security implications, such as erroneously assuming control over the dns @@ -109,7 +109,7 @@ and all of its subdomains. The `dns-account-01` challenge leverages the ACME Account Resource URL to present an account-unique stable challenge to an ACME server. This challenge allows any domain name to delegate its domain validation to more than one service through -ACME account-unique DNS records. +unique per ACME account DNS records. With this new challenge, domain validation of the same DNS name can be done through different authorization labels. Since these authorization labels will depend on the ACME @@ -265,7 +265,7 @@ On receiving a response, the server constructs and stores the key authorization To validate the `dns-account-01` challenge, the server performs the following steps: - Compute the SHA-256 digest {{FIPS180-4}} of the stored key authorization -- Compute the validation domain name with the account URL of the ACME account requesting validation and the associated authorization similar to the client +- Compute the validation domain name with the account URL of the ACME account requesting validation and the associated authorization, similar to the client logic - Query for `TXT` records for the validation domain name - Verify that the contents of one of the `TXT` records match the digest value @@ -293,7 +293,7 @@ In both `dns-account-01` and `dns-02`, the same security considerations apply fo To allow for seamless account key rollover without the label changing, the dynamic part of the label depends on the ACME account and not the account key. This allows for long-lived labels, without the security considerations of keeping the account key static. -In terms of the construction of the label prepended to the domain name, there is no need for a cryptographic hash. The purpose of that is to create a long-lived and statistically distinctive record of minimal size. SHA-256 was picked due to it already being used for existing `dns-01` challenges ({{!RFC8555, Section 8.1}}). +In terms of the construction of the account label prepended to the domain name, there is no need for a cryptographic hash. The goal is to simply create a long-lived and statistically distinct label of minimal size. SHA-256 was chosen due to its existing use in the `dns-01` challenge ({{!RFC8555, Section 8.1}}). The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS record and response size, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. From a383daa8d9e933c4ff4d3e1813c4b3319172154f Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 9 Feb 2024 20:04:30 +0000 Subject: [PATCH 41/43] Formatting and remove a few lines --- draft-ietf-acme-dns-account-01.mkd | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 1c9836f..a5f147c 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -67,11 +67,9 @@ ACME clients validate the domain under the `_acme-challenge` label for the First, the `_acme-challenge` label does not specify if the authorization is intended for a specific host, a wildcard domain, or a domain and all of its -subdomains. Consequently, domain owners who may be delegating or provisioning authorization labels for a domain must concede control over the domain and all subdomains, violating the principle of least privilege. -challenge, the ACME server might be interpreted as validating control over -that DNS name, and potentially its subdomains. This broad validation scope can -have security implications, such as erroneously assuming control over the dns -name and all of its subdomains. +subdomains. Consequently, domain owners who may be delegating or provisioning +authorization labels for a domain must concede control over the domain and all +subdomains, violating the principle of least privilege. Furthermore, since each domain only has a single authorization label, it creates an impediment limiting the number of other entities domain validation can be delegated to. From 81330fb32166516bc7281e80662fddfbcab092c5 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Fri, 9 Feb 2024 20:09:11 +0000 Subject: [PATCH 42/43] Clarify the reason for 10 bytes --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index a5f147c..3385dd7 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -293,7 +293,7 @@ To allow for seamless account key rollover without the label changing, the dynam In terms of the construction of the account label prepended to the domain name, there is no need for a cryptographic hash. The goal is to simply create a long-lived and statistically distinct label of minimal size. SHA-256 was chosen due to its existing use in the `dns-01` challenge ({{!RFC8555, Section 8.1}}). -The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS record and response size, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. +The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS label length, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. # IANA Considerations From b27ebeb2260bd3a8b6a6f1d78126541f8501d114 Mon Sep 17 00:00:00 2001 From: Amir Omidi Date: Sat, 10 Feb 2024 01:55:00 +0000 Subject: [PATCH 43/43] Reference size limits --- draft-ietf-acme-dns-account-01.mkd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-acme-dns-account-01.mkd b/draft-ietf-acme-dns-account-01.mkd index 3385dd7..5bc1a80 100644 --- a/draft-ietf-acme-dns-account-01.mkd +++ b/draft-ietf-acme-dns-account-01.mkd @@ -293,7 +293,7 @@ To allow for seamless account key rollover without the label changing, the dynam In terms of the construction of the account label prepended to the domain name, there is no need for a cryptographic hash. The goal is to simply create a long-lived and statistically distinct label of minimal size. SHA-256 was chosen due to its existing use in the `dns-01` challenge ({{!RFC8555, Section 8.1}}). -The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS label length, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. +The first 10 bytes were picked as a tradeoff: the value needs to be short enough to stay lower than the size limits for DNS ({{!RFC1035, Section 2.3.4}}), long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. # IANA Considerations