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

[Paul Hoffman <[e-mail]>]

On May 27, 2025, at 08:16, Erik Nygren <[e-mail]> wrote:
> 
> I've been thinking about this a bunch, and I think DCV is not necessarily one-time and the current focus on that is counter-productive.  Instead we should be describing what properties are present due to the persistence of a DCV entry, especially since it is public once entered into the DNS.  This relates to how Intermediates fit in as well.  Over the next week or two I'm going to see if I can propose an alternate PR (or set of PRs) that may address some of the concerns here.

A persistent record is not a DCV mechanism because it no longer meets the security model in the draft. The security model is that the user wants to prove to the application service provider that they control the domain, and that no on-path attacker can pretend to be the user. The method is to use an agreed-to random token.

The moment that the user publishes the TXT record, that model falls apart. The on-path attacker can replicate the TXT record. Thus, the validation only works if the application service provider quickly checks the TXT record, before the on-path attacker can replicate it.

This is all fine, and works great; ACME's dns-01 has worked very well for year.

However, saying that a persistent DCV record gives any value under this particular security model is very wrong. The security model for persistent records is completely different, and should not be mixed up with the base security model in draft-ietf-dnsop-domain-verification-techniques. It makes much more sense for a different draft, with a clear and different security model, to define the value of persistent records and their security model.

--Paul Hoffman