> 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 <[email protected]> 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, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
