I think this PR is a fine direction, but it still seems to contain a certain amount of internal confusion. If the security "relies on the causal relationship", then how can it be secure for persistent validation? What is the value of knowing that "either the DNS Administrator of the domain has not chosen to remove the Validation Record or that a new owner of the domain has re-introduced the Validation Record"?
In my view, the core problem is that the draft is dancing around an unstated but essential requirement, for all DNS zones on the internet: 0. We define Validation-Controlling Entries (VCEs) as any records or delegations at underscore-prefixed or wildcard names. 1. Zone owners MUST NOT allow other parties to add or modify a VCE unless the owner name's next label is uniquely assigned to that party. 2. Zone owners MUST NOT add a VCE without understanding and approving its function. 3. When acquiring a zone, the new owner MUST promptly remove all VCEs whose function is not understood and approved. With these requirements in place, we can now speak about validation or authorization in a coherent way: adding a VCE demonstrates approval, so we can confirm approval by requesting a new VCE. We can (and should) also talk about the real reasons that we recommend high-entropy tokens: * As the easiest way to ensure uniqueness in distributed ASP implementations. * As an optional mitigation for failures to comply with requirement #3. * To obfuscate certain vendor-specific identifiers. * To guard against entries accidentally placed in the wrong zone. * etc. --Ben ________________________________ From: John R Levine <[email protected]> Sent: Sunday, June 8, 2025 12:16 PM To: Erik Nygren <[email protected]> Cc: [email protected] <[email protected]> Subject: [DNSOP] Re: [Ext] Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques) On Sun, 8 Jun 2025, Erik Nygren wrote: > Rather than saying "I authorize this action" in a one-off validation, > persistent validation is saying "I authorize this User/account" I don't see a useful difference. Either way the entity issuing the token uses the unique token to identify whatever it is that it wants to verify. As I said before, I do not see any reason to make any technical changes here other than an option for the token to say it does not expire. We can wave our hands about on-path attacker but since I've never seen one attacking a validation token, I'm not aware of any practice we can describe, and I do not want us to guess. Regards, John Levine, [email protected], Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://urldefense.com/v3/__https://jl.ly__;!!Bt8RZUm9aw!9ExScallA0c6qWTIY0LOowCs2r3m3FqIUcAOawol_XK3gU9ZSnPWJj3xGJCWlbZMuqz7dEd2$ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
