> On May 28, 2025, at 19:11, John Levine <[email protected]> wrote: > > It appears that Paul Hoffman <[email protected]> said: >> On May 27, 2025, at 08:16, Erik Nygren <[email protected]> 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
