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

[Henry Birge-Lee <[e-mail]>]

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]
>