[DNSOP] Re: [Ext] Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)

[Erik Nygren <[e-mail]>]

> This is an OK start, but it would be better if the draft covered the
actual security issues (on-path attackers) and dealt with time more
carefully.

Good point.  I've proposed some text on this as part of my PR:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/commit/ac42020800b807dc4d71f70b1145cc86e7a1e268


> Persistent validation doesn't need the token that is needed by the
initial validation.

As mentioned by John, this is critical to include for persistent
validation.  It's a different token (as shown in the draft) but it needs to
be there and it needs to be bound carefully to the User (or User account)
at the Intermediary.  Otherwise the dangling CNAME risks are much much
higher.

Rather than saying "I authorize this action" in a one-off validation,
persistent validation is saying "I authorize this User/account"

I wonder if it would be helpful to explicitly use this "authorization"
language in the draft?

> The new material still doesn't explain why introducing a new mechanism
(intermediaries) should be part of a Best Current Practice RFC.

For the intermediary mechanism being a (best? but at least common) current
practice, here are a number cases where this persistent CNAME to a service
that does one-off validations is being used today for ACME certs by
large-scale CDNs, smaller entities, and an open source project:


   -

   Akamai - Customers CNAME _acme-challenge.domain.com to
   validation.validate-akdv.net
   https://techdocs.akamai.com/property-mgr/docs/add-hn-with-default-cert-la
   -

   Fastly - Customers CNAME _acme-challenge.domain.com to
   token.fastly-validations.com

   https://docs.fastly.com/en/guides/setting-up-tls-with-certificates-fastly-manages
   -

   Cloudflare - Customers CNAME _acme-challenge.domain.com to Cloudflare's
   validation URL (for partial DNS setups)
   https://developers.cloudflare.com/ssl/edge-certificates/changing-dcv-method/methods/delegated-dcv/
   -

   F5 Distributed Cloud - Customers create a CNAME record for _
   acme-challenge.demo.f5lab.com with the value provided by F5 Distributed
   Cloud

   https://f5cloud.zendesk.com/hc/en-us/articles/24624288087959-What-is-an-ACME-challenge-and-how-should-I-enter-these-records-in-my-DNS-zone

   -

   Google Cloud Certificate Manager - Google's Certificate Manager uses DNS
   authorization where customers add CNAME records like _
   acme-challenge.myorg.example.com pointing to Google's validation domains
   for certificate provisioning

   https://cloud.google.com/certificate-manager/docs/deploy-google-managed-dns-auth

   -

   Certify DNS - A cloud hosted version of the acme-dns protocol that uses
   CNAME delegation of ACME challenge TXT records to a dedicated challenge
   response service
   https://docs.certifytheweb.com/docs/dns/providers/certifydns/
   -

   acme-dns (open source) - An open source limited DNS server with RESTful
   HTTP API where customers create CNAME records like
_acme-challenge.domainiwantcertfor.tld
   CNAME a097455b-52cc-4569-90c8-7a4b97c6eba8.auth.example.org
   https://github.com/joohoi/acme-dns

Given how common it is it seems to be important to cover how to do this
safely (eg, but having a high-entropy binding to an account identifier in
the CNAME target).

Best, Erik




On Sat, Jun 7, 2025 at 9:33 AM John R Levine <[e-mail]> wrote:

> On Fri, 6 Jun 2025, Paul Hoffman wrote:
> > This is an OK start, but it would be better if the draft covered the
> actual security issues (on-path attackers) and dealt with time more
> carefully. Persistent validation doesn't need the token that is needed by
> the initial validation.
>
> Why not?  Let's say I have three accounts with FooCo and then cancel one
> of them.  It needs something more than "I have some relationship with
> FooCo".
>
> I don't object to documenting on-path attackers but it still seems
> awfully hypothetical.
>
> > The new material still doesn't explain why introducing a new mechanism
> (intermediaries) should be part of a Best Current Practice RFC.
>
> I agree with that bit.
>
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>