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

[Ben Schwartz <[e-mail]>]

I think we should put these rules in the draft, prominently.  The top of the Security Considerations would probably be fine.  We should probably emphasize that these requirements bind all zones on the internet, even those that have no interest in using DCV and predate this specification.  (I wish they had been in RFC 8552 ... oh well.)

I don't think VCE is a synonym for "Validation Record".  For example, any NS record that creates a delegation at an underscore label is a VCE, because the child could install a TXT record at the apex (and our validation rules don't require ASPs to reject this).  Same for CNAMEs at wildcards (which could match an underscore label), etc.

I'm not attached to the name "VCE", but I was trying to convey that (1) letting other parties install delegations at these points is prohibited and (2) this is the category of things that can influence the results of DCV.

--Ben
________________________________
From: Erik Nygren <[e-mail]>
Sent: Monday, June 9, 2025 12:29 PM
To: Ben Schwartz <[e-mail]>
Cc: John R Levine <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [DNSOP] Re: [Ext] Persistence of DCV, including for Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)

> 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

> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, June 8, 2025 12:16 PM
To: Erik Nygren <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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, [e-mail]<mailto:[e-mail]>, 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>