[Acme] Re: I-D Action: draft-ietf-acme-dns-persist-01.txt

[Mike Ounsworth <[e-mail]>]

Hi Henry,

TL;DR:
[Chair Hat]
Process-wise, we have identified a privacy concern with this draft (and
incidentally also with RFC 8657). Specifically, do we think that static
ACME Account URIs in DNS records leaking which domain names belong to the
same operator / ACME client is a privacy leak worth doing something about?
Having been identified, I think the WG needs to have the discussion and
come to consensus about whether this is worth addressing, or if we think
it's fine the way it is.



First, I worked at a public CA for 10 years as a hands-on security and
compliance tester, so I am very sympathetic to how complex technical
standards lead to operational problems for the CA. But in this context, I'm
wearing my ACME WG Chair hat and reminding us that while the IETF's
institutional stance does take into consideration vendor implementation
burden, in a conflict between implementation complexity and end user
privacy, end user privacy should win.

Second, I'm not really proposing a solution here -- I've only been thinking
about this for a grand total of like 5 minutes -- I'm just strawmanning
art-of-the-possible.

I see your point about making this hard to manually configure, and I think
that's valid to consider. Almost certainly that's something we can design
around. It might even be a point that can be solved by CA API design rather
than RFCs -- ex.: the CA could compute SHA256(accounturi || domain_name)
for you and show it to you in a UI; as long as it's possible for clients to
compute it independently and for researchers to verify that it's unique and
non-linkable according to the spec, then there's no problem with that. To
me, a design like that would be "fail closed" in that an implementer could
screw it up to not work at all (ie is incompatible with at least some
clients), but can't screw it up so that it works insecurely.

About the point "But CAA already uses plaintext AccountURI": I don't think
that talking about security and privacy improvements of existing RFCs
should be off the table. In this case, CAA (RFC 8657) is also an ACME WG
document, so we have the power to update it if, in retrospect, we think
that Security Consideration 5.9. Revelation of Account URIs wasn't strong
enough and we want to improve it.


> I first don't fully agree with the "fail open" point. If a subscriber
chooses to use an anonymized account uri there is no way to downgrade that
to break the anonymity.

Can you please expand on that? I don't see in this draft or in RFC 8657
where it specifies that the subscriber must be able to choose their own
account uri per order. Am I missing something? I thought typically those
are long-term identifiers assigned by the CA and the subscriber has no
control over them.
Or are you assuming that some CAs will offer Anonymized Account URI as a
feature? I suspect that even if some CAs offer that, not all 120 CAs in the
CCADB will. This is what I mean by "fail open" on an optional privacy
feature. If we're not mandating something then we don't get to assume that
it'll be implemented. If that thing has user privacy implications that we
think are important, then we probably should be mandating it.




On Fri, 24 Apr 2026 at 12:34, Henry Birge-Lee <[e-mail]>
wrote:

> Hi all,
>
> First regarding Seo's point: I have spoken to several other CAB/F
> participants about these types of privacy-focused account URIs and
> everybody I have spoken with is in favor of allowing this. I would also say
> that the general consensus that was present when Slaughter drafted the
> CAB/F ballot and (has to the best of my knowledge) persisted since is that
> the current language does allow these types of techniques. "identifying"
> needs only to be done by the CA and the schemes proposed here are
> sufficient for these purposes.
>
> Mike: you take a very IETF purist approach to this (which I appreciate). I
> will say that we are not the original sin here. The model for this approach
> was based off of RFC 8657 which, if it were to get used in mass, would
> create his same privacy leaking channel. I do think that the privacy
> conversations are slightly more relevant on this draft as we are
> introducing a mechanism that could save domain owners time and has the
> potential to see much larger adoption than RFC 8657 which was always an
> additional security mechanism (domain owners historically have not turned
> on a lot of the "extra" security features available to them).
>
> My overall stance on this is that the system you propose
> (SHA256(accounturi || domain_name)) is the logical recommended practice for
> avoiding this privacy issue and may be worth mentioning in the draft. I
> have had some CAs mention they would prefer just using a CA-side lookup
> table to avoid the technicalities of properly computing the hash, but I
> personally don't think this is too challenging. There is another
> interesting element to including this hash mechanism in the draft. Many CAs
> act as if RFCs (including those not referenced by the CAB/F) have
> implications for their compliance. This attitude I think causes CAs to
> prefer RFCs with as few algorithms specified as possible which creates the
> least compliance risk. I don't expect the WG will be particularly
> sympathetic to this stance, but I think its worth mentioning as compliance
> issues and overly-complex standards can cause real damage in the CA
> ecosystem.
>
> As for: does SHA256(accounturi || domain_name) need to be a mandated
> approach? I first don't fully agree with the "fail open" point. If a
> subscriber chooses to use an anonymized account uri there is no way to
> downgrade that to break the anonymity. I do see the point of path of least
> resistance and CAs will probably just operate with the default ACME account
> URI and create this leakage channel no matter how many security
> considerations we put in. However, I sort of see this from a broader
> perspective:
>
> 1. Consistency among standards is important. RFC 8657 already introduced
> this (including use of the traditional account URI) and the syntax of this
> record is largely copied from that standard. I have hesitation implementing
> anything that would make RFC 8657-style records invalid in this context.
> There is a security pro to this as well that some could recommend copying a
> dns-persist  record into a CAA record for added security and this could
> cause an uptick in RFC 8657 adoption so long as the standards are
> compatible.
>
> 2. Simplicity of standards is important: I expect many people will upload
> this record by hand. Its not too hard to find the ACME account uri and then
> manually construct <ca name>; accounturi=<account uri from ACME command>.
> As soon as we put in a hashing requirement, the amount of effort for this
> manual construction goes up like 10x. Have you ever tried to validate a
> NSEC3 record by hand? Its doable but a real hassle and you never really
> know if you got it right until you try it. Obviously simple tooling could
> help with these records but if there is a way to keep them human readable
> and human writable I think that is preferred.
>
> 3. Are we really fixing anything? The CAB/F ballot already permits normal
> account URIs for CA subscriber accounts. Making this ACME draft mandate
> hashed account URIs doesn't fully close this channel. Also, if you are
> concerned about people taking the easy way out, as long as non-ACME
> supports "easy" account uris, people might just use ACME less to avoid the
> hassle.
>
> I normally target security and privacy that is comparable to the broader
> ecosystem a technology is embedded in and here there are two precedents
> that do not have this level of security (RFC 8657 and the CAB/F ballot).
> Thus, I have some hesitation forcing applicants to use the hashed account
> URIs, but I am open to including this technique in the draft and possibly
> replacing the CA lookup table approach. I still think good old simple
> account URIs should still be accepted.
>
> Best,
> Henry
>
> On Thu, Apr 23, 2026 at 8:32 PM Seo Suchan <[e-mail]> wrote:
>
>> 1. ACME accounturi wasn't required to be random.: current Let's Encrypt's
>> accounturi format is just a counter from 0 for each accounts it registered
>> after https://acme-v02.api.letsencrypt.org/acme/acct/ , so it's trivial
>> to try every account it have if there is a match.
>>
>>
>> 2. CAB side of persistence dcv requirement have this paragraph:
>> (3.2.2.4.22)
>>
>>  can said if outside observer can't know which account it points to
>>
>> >The issue-value MUST contain an accounturi parameter, where the
>> parameter value is
>> >a unique URI (as described by RFC 8657, Section 3) identifying the
>> account of the Applicant
>> >which requested validation for this FQDN;
>>
>> on could say if 3rd part don't know which account txt record it points to
>> that isn't 'identifying' an account. I think we should add this anyway but
>> I thought I should mention this.
>> 26. 4. 24. 12:16에 Mike Ounsworth 이(가) 쓴 글:
>>
>> Hi Shiloh,
>>
>> > On the privacy point, I think the right approach is for the CA to issue
>> distinct opaque aliases per validation domain name, or per small group of
>> domains, rather than reusing one visible identifier everywhere. That avoids
>> cross-domain correlation without needing to change `accounturi` to an array.
>>
>> I do think that Security Consideration section 7.2.2 is well-written and
>> clear about the benefits and risks related to using anonymous aliases here
>> -- that CAs who care about privacy issuing to subscribers who care about
>> privacy should use the anonymized alternative URI scheme described in 7.2.2.
>>
>> But I think the point being raised here is that the mechanism described
>> by 7.2.2 is fail-open; ie if a lazy CA uses non-anonymized URIs here, then
>> the subscriber doesn't get privacy, and that's it. In particular, as I
>> understand it, the ACME WG would be building a mechanism into the ACME
>> protocol that leaks extremely publicly which domains belong to the same
>> ACME account.
>>
>> Reminder about RFC7258:
>>
>> Abstract
>>
>>    Pervasive monitoring is a technical attack that should be mitigated
>>    in the design of IETF protocols, where possible.
>>
>>
>> So I think it's worth putting our thinking hats on about whether we can
>> design the acme dns-persist-01 mechanism so that unique non-linkable tokens
>> are baked into the protocol. For example, if the client constructs the
>> token out of pieces of the order object, such as SHA256(accounturi ||
>> domain_name) or HMAC(domain_name, accounturi). In practice, accounturi is
>> basically a high-entropy secret, right, so salt it with the domain name and
>> you've got something that's unique per domain, easy to construct and
>> validate, and into password cracking or bitcoin mining territory to
>> de-anonymize. And now, the laziest possible CA implementation is to compute
>> SHA256(accounturi || domain_name) at the time of the neworder and stick it
>> in a lookup table, and now the behaviour we wanted in the first place is
>> the "short-cut" instead of something we have to beg for in a Security
>> Consideration.
>>
>> (that said, I'm not super familiar with the specifics and motivations of
>> this draft, so I'd be happy if I'm off-base)
>>
>>
>> On Wed, 15 Apr 2026 at 13:36, Shiloh Heurich <shiloh=
>> [e-mail]> wrote:
>>
>>> On Apr 4, 2026, at 01:17, Seo Suchan <[e-mail]> wrote:
>>> >
>>> > accounturi in 3.1 challenge object need to be arrays of string not a
>>> single string to be used to be able to give any alternative uris: currently
>>> there is only one choice for client. to actually able to hide record we'd
>>> need something per domain name: hmac that uses account publickey as shared
>>> key and domain name as message?
>>>
>>> I think this raises two distinct questions:
>>>
>>> 1. Does the challenge object need to carry multiple acceptable
>>> `accounturi` values?
>>> 2. Does the current alternative-URI text provide meaningful privacy?
>>>
>>> My reading is that an array is not necessary if the intended model is
>>> that the CA tells the client the single `accounturi` value it expects in
>>> DNS for that validation attempt. That value could be either the canonical
>>> ACME account URL or a CA-issued opaque alias for the same account. In this
>>> model the client does not need a choice; it just uses the value from the
>>> challenge.
>>>
>>> I agree that the draft is not clear enough on this today. The current
>>> text about the client verifying that an alternative URI "identifies the
>>> same account" is confusing. If the CA provides an opaque alternative URI,
>>> the client generally cannot verify that mapping independently and has to
>>> rely on the challenge object.
>>>
>>> On the privacy point, I think the right approach is for the CA to issue
>>> distinct opaque aliases per validation domain name, or per small group of
>>> domains, rather than reusing one visible identifier everywhere. That avoids
>>> cross-domain correlation without needing to change `accounturi` to an array.
>>>
>>> I do not think an HMAC construction using the account public key is the
>>> right primitive here. HMAC requires a secret key, and the account public
>>> key is public. If a CA wants deterministic per-domain aliases internally,
>>> that is better treated as a CA implementation detail using CA-held secret
>>> material, not something the client derives.
>>>
>>> My preference would be to:
>>> - keep `accounturi` as a single string,
>>> - clarify that it is the specific value the CA expects for that
>>> validation attempt,
>>> - clarify that privacy-preserving alternatives may be per-domain opaque
>>> aliases, and
>>> - clarify that pre-provisioning without a challenge uses the canonical
>>> account URL unless the CA provides alternatives (e.g. out of band).
>>>
>>> If there is a concrete case where the client needs to choose among
>>> multiple simultaneously valid identifiers, then an array may be worth
>>> considering. For now, this seems more like a clarity problem than a
>>> field-shape problem.
>>>
>>> Shiloh
>>>
>>> _______________________________________________
>>> Acme mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> Acme mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>