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

[Paul Hoffman <[e-mail]>]

> On May 28, 2025, at 19:11, John Levine <[e-mail]> wrote:
> 
> It appears that Paul Hoffman  <[e-mail]> said:
>> 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.
> 
> I would just document the fact that the threat model is different and move on.  I realize that
> in principle an on-path attacker has more opportunity to return fake results, but it is my
> impression that situations with malicious fake results, and particularly fake results that
> wouldn't be apparent immediately, are quite rare.

If the WG goes with "they are rare", then there is no need for the random number, which would be a hard sell to the security community. I still think it is better to have this document have the well-understood security model for initial verification (and state it better), and a different draft for persistence with a different security model (that is stated at all, since it is not in the current draft). We have lots of use cases for the former, but few commonly-seen ones for the latter.

--Paul Hoffman