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. 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. 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. Från: [email protected] <[email protected]> För zandoodle Skickat: den 5 april 2026 03:48 Till: [email protected] Ä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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
