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

[Matthew McPherrin <[e-mail]>]

I think that if we want to standardize restricting source IPs, it should be
independent of the challenge type.

Perhaps another CAA record extension like accounturi from rfc8657.

There are many technical details to resolve such that it really merits its
own discussion (and weaknesses, like trusting your CDN to tell you the
connecting client IP, as Shiloh mentions).

On Tue, Mar 24, 2026 at 7:00 AM Shiloh Heurich <shiloh=
[e-mail]> wrote:

> On Mar 24, 2026, at 01:47, Seo Suchan <[e-mail]> wrote:
>
> someone on Let's encrypt forum wanted to add an extension to this to limit
> validation to be from a specific IP.
>
> https://community.letsencrypt.org/t/dns-persist-01-add-ability-to-filter-request-ip/246091
>
> I personally think it'd be better be a extension of RFC8657 than specific
> for dns-persist-01 but still interesting proposal to discuss here.
>
>
> Thanks for the pointer.
>
> The forum poster wants source IP restrictions to replace the DNS API key
> that dns-persist-01 removes from the issuance path. The problem is that
> source IP does not work as an independent second factor. CDN and cloud IP
> ranges are shared infrastructure. If the legitimate client's requests
> traverse a CDN, an attacker with the stolen key routes through the same CDN
> and arrives from the same IP range. The constraint does not distinguish
> between the legitimate client and an attacker on the same network. For
> dedicated infrastructure with a static IP the constraint is stronger, but
> it also reintroduces the DNS maintenance dependency that dns-persist-01 was
> designed to remove.
>
> This applies regardless of where the parameter lives — dns-persist-01 TXT
> record or CAA.
>
> Shiloh
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>