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

[Ben Schwartz <[e-mail]>]

I'm open to either view on this.  My main concerns are:

1. The draft's recommendations should be logically consistent with its stated threat model.
2. The draft should clearly define terminology and use it consistently.
3. The purpose of each record should be clear to someone reading the zone file.
4. It should be obvious whether or not a record can safely be removed from the zone.
5. We should favor human-readable values where possible.

If we decide to support persistence of DCV records, this means we need to adjust the threat model, lean harder on the "expiry" key (or similar), and consider whether the persistent authorization function should be accomplished by a human-readable value, even if it shares a single TXT record with the random token.

--Ben
________________________________
From: Paul Hoffman <[e-mail]>
Sent: Tuesday, May 27, 2025 8:55 PM
To: Erik Nygren <[e-mail]>
Cc: dnsop WG <[e-mail]>
Subject: [DNSOP] Re: [Ext] Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)

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

_______________________________________________
DNSOP mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]