[Acme] Re: Potential issues with dns-persist-01

[Shiloh Heurich <[e-mail]>]

Thanks for the correction; pre-provisioning is vulnerable for the same reason as the standard challenge flow.

Your token proposal would catch the case where the rogue server returns a URI at a real CA i.e. the client POSTs, the real CA rejects the key mismatch, and the client detects the problem. But it adds an online step, which is one of the things pre-provisioning is designed to avoid.

An `accountkey=` parameter with a self-computed thumbprint addresses this without the online requirement. The client derives it from its own key material regardless of what the server told it. That should cover both flows.

> On Apr 17, 2026, at 10:35, zandoodle <[e-mail]> wrote:
> 
> I'm sorry I didn't make it clear in my initial email that the attacks were on the accounturi provided when making a new account and so affected pre-provisioned records.
> 
> It should be possible to allow arbitrary account URIs so long as the client can verify them, one way I've proposed is to have the client make a POST request to the account URI and receive a token which can then be put in the TXT record alongside the account URI.
> 
> This (alongside server-side validation of the URI) will allow the CA to confirm that the client has verified their account against a CA controlled endpoint.
> 
> On 17/04/2026 12:39, Shiloh Heurich wrote:
>> Your analogy to the http-01 token substitution is correct. In the standard challenge flow, the dns-persist record contains no client-computed cryptographic material, so the same class of attack applies. RFC 8555 §10.2 describes this pattern formally and explains why Key Authorization was designed to prevent it. The draft should address this.
>> 
>> Pre-provisioning is a different story and the thread hasn't raised it. In that flow there's no challenge object. The client constructs the record from its own account URL (the §7.3 Location header) and the `issuer-domain-name` from directory metadata or the CP/CPS. No server-provided value to substitute. This is the primary deployment model for the enterprise and multi-tenant cases the draft targets.
>> 
>> The harder problem is that persistence and key binding work against each other. Key Authorization works for http-01 and dns-01 because those values are ephemeral: provision, validate, remove, rotate the key freely. A persistent record containing Thumbprint(accountKey) means every key rotation (§7.3.5) invalidates every dns-persist record across every domain on the account. For subscribers with hundreds or thousands of domains, that defeats the purpose of a persistent method. The draft chose accounturi because it's stable across rotations.
>> 
>> Persistence, cryptographic key binding, key rotation support: pick two. That's the core tension.
>> 
>> I see three options, roughly by disruption level:
>> 
>> (a) Strengthen client verification within the current design. Upgrade the §3.1 SHOULD to MUST when the client knows its own account URL. Add explicit security analysis of the missing dual-channel binding and the rationale. Qualify the "strong binding" language in §7.2.
>> 
>> (b) Add an optional accountkey= parameter carrying base64url(Thumbprint(accountKey)), always self-computed by the client. When present, the CA verifies the thumbprint matches the current key. Restores dual-channel binding when used, but clients accept that rotation means updating DNS records. The forward-compatibility rule (MUST ignore unknown parameters) means existing implementations won't enforce it, so this only helps against CAs that opt in.
>> 
>> (c) Sebastian's pubkey: scheme in accounturi. Max already noted the problem: a malicious server can tell the client its accounturi is pubkey:<attacker-thumbprint>. Always-self-compute as a mitigation requires the client to distinguish pubkey URIs it should compute from regular URIs it should provision as-is. That seems fragile.
>> 
>> I'd go with (a) for -02, possibly (b) as a follow-on. But the real question for the WG is whether the pre-provisioning distinction is sufficient, or whether the standard challenge flow needs cryptographic binding even at the cost of rotation compatibility.
>> 
>> Shiloh
>