Content-Type: multipart/alternative;
 boundary="------------qiCv0Ot7TQ6Y6g8JYcKAU1zy"
Message-ID: <a550982b-9404-42d5-932e-50330bc43593@gmail.com>
Date: Sun, 5 Apr 2026 17:25:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: acme@ietf.org
References: 
 <CAFg2froJTxp+kT_VdSuNs9LVqFQhO-WJZBt=-qoVQO9c8M+=Xw@mail.gmail.com>
 <000701dcc4a1$bd2130c0$37639240$@sebbe.eu>
 <99830dd3-4157-41b1-970f-e81052f5da7f@gmail.com>
 <02296D08-5FA3-449B-A1C6-960D759DF983@gmail.com>
Content-Language: en-US
From: zandoodle <maxoscarhearnden@gmail.com>
In-Reply-To: <02296D08-5FA3-449B-A1C6-960D759DF983@gmail.com>
Message-ID-Hash: PBXWCCUOMP7TWO45NKO6OHH77XQUQOQD
Precedence: list
Subject: =?utf-8?q?=5BAcme=5D_Re=3A_Potential_issues_with_dns-persist-01?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/acme/eMmmT1yr6cAOAWYZ5dyZN8Y9ufs>

This is a multi-part message in MIME format.
--------------qiCv0Ot7TQ6Y6g8JYcKAU1zy
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

That would prevent attack 1 (Attacker controlled account on CA's origin) 
however it could also allow the attacker to return their CA account URI 
(or whatever was provided in the account) for an account (not registered 
with the CA) on the attacker's origin.

Maybe it should be a token alongside the account URI, e.g. 
_validation-persist TXT 
"letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acct/123456;token=<persist-token-from-account-api>". 
This would provide proof to the issuing CA that the client has verified 
their key for their account for which the success response was protected 
by HTTPS.

On 05/04/2026 14:54, Seo Suchan wrote:
> For this spicific attack As this accounturi doesn't change between 
> challenge domains, can we move it inside of actual account endpoint? 
> If client need to use actual accounturi they'd found it can't use that 
> accounturi because is doesn't have publickey  for that account.
> In general if you want cryptopical binding you'd need to use crypto 
> key. Don't think full mitm version of this attack can be prevented 
> while we using accounturi not account public key.
>
>
> On 2026년 4월 5일 오후 10시 23분 13초 GMT+09:00, zandoodle 
> <maxoscarhearnden@gmail.com> 작성함:
>
>     Sorry for the late reply, I couldn't find how to reply to an email
>     in a mailing list digest in the gmail web client. On 05/04/2026
>     03:13, Sebastian Robin Nielsen wrote:
>
>         Both of these attacks rely on violation of the ”On First
>         Trust” principle. It works like a SSH key, which you must
>         verify on first use. You as a domain owner, are supposed to
>         verify the accounturi is yours, before setting up a
>         dns-persist-01 record. 
>
>     I was having the client be provided the attacker's account URI
>     when they visited the newAccount endpoint which could make the
>     client think that they owned the attacker's account URI, attack 1
>     relied on there currently being little reason to make a POST
>     request to the account URI which appears to be the only way to
>     verify ownership of an account.
>
>         About: ” The first attack could be prevented by having the
>         client by making a POST request of some sort to the account
>         URI which allows them to verify that their key is valid for
>         the account.” If the attacker has control over the
>         communication, the attacker could replace that communication too. 
>
>     I was having the attacker not be in control of communications to
>     the legitimate CA and instead have their own domain e.g.
>     https://dns-persist-testing.attacker.example, a request to the
>     account URI under the legitimate CA's domain would still be
>     protected by HTTPS.
>
>         One way to improve the protocol, would be to allow the
>         accounturi be a SHA256 hash of the public key. Like:
>         _validation-persist.YOURDOMAIN.TLD 3600 IN TXT
>         "letsencrypt.org;accounturi=pubkey:
>         135b12725a113862143f7cc14bfbb56e66eefe86158769f6128e9da9f463998a;policy=wildcard"
>         This would allow the domain owner to provision the record even
>         long before the account is created and given an account uri,
>         which means the generation of the DNS record can happen
>         locally long before any ACME server on the internet even sees
>         a internet packet. 
>
>     It could also discourage ACME clients from implementing an account
>     key rollover which could make one time access to the account's
>     private key in to a persistent threat. I know that a key
>     compromise is already bad, however an account key rollover (which
>     could be performed regularly) would either regain control or
>     provide an indication of a compromise for the legitimate system.
>
>         *Från:*forwardingalgorithm@ietf.org
>         <forwardingalgorithm@ietf.org> *För *zandoodle *Skickat:* den
>         5 april 2026 03:48 *Till:* acme@ietf.org *Ämne:* [Acme]
>         Potential issues with dns-persist-01 Hello, IETF participants
>         I'm somewhat concerned about the lack of binding between an
>         account's key, the challenge and the certificate request. This
>         could lead to two new similar attacks against a user's domain.
>         1.An attacker sets up an ACME server and convinces the client
>         to use it, the client is then provided the attacker's ACME
>         account on the CA's domain and instructs the client to setup
>         dns-persist-01 under the attacker's account. 2.An attacker
>         sets up an ACME server and convinces the client to use it, the
>         client is then provided the attacker's ACME account for the
>         attacker's domain and instructs the client to setup
>         dns-persist-01 under the attacker's account. This requires
>         that the certificate authority allows accounts to be created
>         under the attacker's domain e.g. creating the account under
>         the domain in the Host header field as done by Let's Encrypt.
>         dns-01, http-01 and tls-alpn-01 all have the client's ACME
>         account's public key as part of the challenge so the client's
>         account and the account the certificate authority is issuing
>         to must be the same. The first attack could be prevented by
>         having the client by making a POST request of some sort to the
>         account URI which allows them to verify that their key is
>         valid for the account. The second attack could be prevented by
>         the certificate authority by verifying the account-uri is both
>         https and on a domain they control when verifying/offering the
>         dns-persist-01 challenge or by restricting the domains under
>         which an account can be created. Both attacks could also be
>         prevented by having the client check that the directory,
>         account URI and issuer domain name have the same domain name
>         however this might be overly restrictive. The issuer domain
>         name might not be sufficient protection as the server
>         instructs the client as to what it should be. Given the strong
>         security requirements for the issuer domain names including
>         DNSSEC but with no requirement to resolve the domain names,
>         maybe the authors intended to put metadata at the issuer
>         domain names. 
>
>     ------------------------------------------------------------------------
>     Acme mailing list -- acme@ietf.org To unsubscribe send an email to
>     acme-leave@ietf.org
>
--------------qiCv0Ot7TQ6Y6g8JYcKAU1zy
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>That would prevent attack 1 (Attacker controlled account on CA's
      origin) however it could also allow the attacker to return their
      CA account URI (or whatever was provided in the account) for an
      account (not registered with the CA) on the attacker's origin.</p>
    <p>Maybe it should be a token alongside the account URI, e.g.
      _validation-persist TXT
"letsencrypt.org;accounturi=<a class="moz-txt-link-freetext" href="https://acme-v02.api.letsencrypt.org/acct/123456;token=">https://acme-v02.api.letsencrypt.org/acct/123456;token=</a>&lt;persist-token-from-account-api&gt;".
      This would provide proof to the issuing CA that the client has
      verified their key for their account for which the success
      response was protected by HTTPS.</p>
    <div class="moz-cite-prefix">On 05/04/2026 14:54, Seo Suchan wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:02296D08-5FA3-449B-A1C6-960D759DF983@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">For this spicific attack As this accounturi
        doesn't change between challenge domains, can we move it inside
        of actual account endpoint? If client need to use actual
        accounturi they'd found it can't use that accounturi because is
        doesn't have publickey  for that account.<br>
        In general if you want cryptopical binding you'd need to use
        crypto key. Don't think full mitm version of this attack can be
        prevented while we using accounturi not account public key.<br>
      </div>
      <br>
      <br>
      <div class="gmail_quote">
        <div dir="auto">On 2026년 4월 5일 오후 10시 23분 13초 GMT+09:00,
          zandoodle <a class="moz-txt-link-rfc2396E" href="mailto:maxoscarhearnden@gmail.com">&lt;maxoscarhearnden@gmail.com&gt;</a> 작성함:</div>
        <blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
          <pre class="com-fsck-k9__plain-text-message-pre"><div
          dir="auto">Sorry for the late reply, I couldn't find how to reply to an email in a mailing list digest in the gmail web client.

On 05/04/2026 03:13, Sebastian Robin Nielsen wrote:
</div><blockquote class="gmail_quote"
style="margin-bottom: 1ex; --com-fsck-k9__blockquote-default-border-color: #729fcf;"><div
          dir="auto">
Both of these attacks rely on violation of the ”On First Trust” principle.

It works like a SSH key, which you must verify on first use.

You as a domain owner, are supposed to verify the accounturi is yours, before setting up a dns-persist-01 record.

</div></blockquote><div dir="auto">I was having the client be provided the attacker's account URI when they visited the newAccount endpoint which could make the client think that they owned the attacker's account URI, attack 1 relied on there currently being little reason to make a POST request to the account URI which appears to be the only way to verify ownership of an account.
</div><blockquote class="gmail_quote"
style="margin-bottom: 1ex; --com-fsck-k9__blockquote-default-border-color: #729fcf;"><div
          dir="auto">
About:

” The first attack could be prevented by having the client by making a POST request of some sort to the account URI which allows them to verify that their key is valid for the account.”

If the attacker has control over the communication, the attacker could replace that communication too.

</div></blockquote><div dir="auto">I was having the attacker not be in control of communications to the legitimate CA and instead have their own domain e.g. <a
          href="https://dns-persist-testing.attacker.example"
          moz-do-not-send="true" class="moz-txt-link-freetext">https://dns-persist-testing.attacker.example</a>, a request to the account URI under the legitimate CA's domain would still be protected by HTTPS.
</div><blockquote class="gmail_quote"
style="margin-bottom: 1ex; --com-fsck-k9__blockquote-default-border-color: #729fcf;"><div
          dir="auto">
One way to improve the protocol, would be to allow the accounturi be a SHA256 hash of the public key.

Like:

_validation-persist.YOURDOMAIN.TLD 3600 IN TXT "letsencrypt.org;accounturi=pubkey: 135b12725a113862143f7cc14bfbb56e66eefe86158769f6128e9da9f463998a;policy=wildcard"

This would allow the domain owner to provision the record even long before the account is created and given an account uri, which means the generation of the DNS record can happen locally long before any ACME server on the internet even sees a internet packet.

</div></blockquote><div dir="auto">It could also discourage ACME clients from implementing an account key rollover which could make one time access to the account's private key in to a persistent threat. I know that a key compromise is already bad, however an account key rollover (which could be performed regularly) would either regain control or provide an indication of a compromise for the legitimate system.
</div><blockquote class="gmail_quote"
style="margin-bottom: 1ex; --com-fsck-k9__blockquote-default-border-color: #729fcf;"><div
          dir="auto">
*Frå<a class="moz-txt-link-abbreviated" href="mailto:n:*forwardingalgorithm@ietf.org">n:*forwardingalgorithm@ietf.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:forwardingalgorithm@ietf.org">&lt;forwardingalgorithm@ietf.org&gt;</a> *För *zandoodle
*Skickat:* den 5 april 2026 03:48
*Till:* <a class="moz-txt-link-abbreviated" href="mailto:acme@ietf.org">acme@ietf.org</a>
*Ämne:* [Acme] Potential issues with dns-persist-01

Hello, IETF participants

I'm somewhat concerned about the lack of binding between an account's key, the challenge and the certificate request. This could lead to two new similar attacks against a user's domain.

1.An attacker sets up an ACME server and convinces the client to use it, the client is then provided the attacker's ACME account on the CA's domain and instructs the client to setup dns-persist-01 under the attacker's account.

2.An attacker sets up an ACME server and convinces the client to use it, the client is then provided the attacker's ACME account for the attacker's domain and instructs the client to setup dns-persist-01 under the attacker's account. This requires that the certificate authority allows accounts to be created under the attacker's domain e.g. creating the account under the domain in the Host header field as done by Let's Encrypt.

dns-01, http-01 and tls-alpn-01 all have the client's ACME account's public key as part of the challenge so the client's account and the account the certificate authority is issuing to must be the same.

The first attack could be prevented by having the client by making a POST request of some sort to the account URI which allows them to verify that their key is valid for the account.

The second attack could be prevented by the certificate authority by verifying the account-uri is both https and on a domain they control when verifying/offering the dns-persist-01 challenge or by restricting the domains under which an account can be created.

Both attacks could also be prevented by having the client check that the directory, account URI and issuer domain name have the same domain name however this might be overly restrictive.

The issuer domain name might not be sufficient protection as the server instructs the client as to what it should be. Given the strong security requirements for the issuer domain names including DNSSEC but with no requirement to resolve the domain names, maybe the authors intended to put metadata at the issuer domain names.

</div></blockquote><div dir="auto"><hr>Acme mailing list -- <a class="moz-txt-link-abbreviated" href="mailto:acme@ietf.org">acme@ietf.org</a>
To unsubscribe send an email to <a class="moz-txt-link-abbreviated" href="mailto:acme-leave@ietf.org">acme-leave@ietf.org</a>
</div></pre>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>

--------------qiCv0Ot7TQ6Y6g8JYcKAU1zy--