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

[Paul Wouters <[e-mail]>]

On Fri, 30 May 2025, John R Levine wrote:

> On Fri, 30 May 2025, Joe Abley wrote:
>>  I have definitely received automated email telling me that my domain is
>>  about to be detached from a particular service because the TXT record had
>>  been removed. Other TXT records I have been removed in the interests of
>>  hygiene had no such effect.
>>  I agree that consistency would be better than this state of affairs.
>
> It seems to me that a DCV in the form we use is no worse than anything else 
> persistent that's going to be in the DNS.  The point of the random token is 
> to show that the person publishing the DNS record is the one with the account 
> to be verified, but once it's published the cat is out of the bag.  I don't 
> see any way to fix that other than periodically changing the token, and if 
> you're going to do that, you know where to find ACME.

Indeed, but is a cron job really a method to confirm continued
acceptance of a service? It requires credentials to make a DNS
change and in a way only weakens the security model. (just like ACME
using DNS-01 doesn't add anything to just publishing TLSA records in
the DNS)

>>  It also seems possible that there is a need for two signals: that a domain
>>  is authorised to onboard to a particular service, and that a domain is
>>  authorised to continue to be linked to a service.
>
> I would guess that the chances of the places that use DCV would use two 
> different signals is on the order of 0.001%.  I suppose a flag like 
> expiry=indefinite rather thean exppiry=260123 could give DNS people a hint of 
> which ones are OK to delete.

Which is what we did in more detail in previous versions of this draft.
Some in the WG thought this was too complex, and we toned it down a bit.

I don't see many people disagreeing with your statement here on a simple
expire= RRdata content. I would be happy to restore some of this text,
eg like the old version had:

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03#section-5.2.1

It would be great if the Chairs could do some consensus call on this, so
the authors know how to resolve this discussion point.

> PS: The threat model for faked long term DCV seems rather implausible. A 
> malicious actor is going to fool some SaaS company into continuing my 
> subscription so they can steal it?  That's going to be hard to do once I 
> don't pay the bill.

Yes. The model mostly assumes a new domain owner wouldn't copy old
content and so any services will get quickly decomissioned when the
domain owner changes. This is not about active attackers.

Paul W