> 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:
I think this is a reasonable summary. For better or worse, domain control
validations are being used as what you describe as "validation-controlling
entities" today in both one-off and persistent manners. The things you
list are likely some of the best practices needed to make them safe.
How should we capture this? Do we want to incorporate this into both
"Purpose of DCV" as well as into some other section(s)?
Do we want to introduce this term Validation-Controlling Entries or just
use Validation Records as we have in the glossary already? If they are
different how are they different?
Erik
On Mon, Jun 9, 2025 at 10:50 AM Ben Schwartz <[email protected]> wrote:
> 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]
