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

[Erik Nygren <[e-mail]>]

There are two cases here:

1) Accidental retention of zone contents (this seems unlikely, but worth
mentioning)
2) Malicious reintroduction of zone contents (this is the concern we need
to make sure is well-addressed, and is one of the reasons it is critical
that validations are tied to users/accounts).

The latter case is a bit of a contortion as well (the new owner could
request a new validation) but there are some potential sharp edges that an
attacker might be able to take advantage of depending on the details of the
application.

     Erik



On Wed, Jun 11, 2025 at 9:59 AM Ben Schwartz <bemasc=
[e-mail]> wrote:

> I agree: transferring records blindly from a previous owner of a domain
> would be bizarre.  However, the draft currently says:
>
> > Subsequent validation actions using an already disclosed token are no
> guarantee that the original owner is still in control of the domain
>
> (
> https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-07.html#section-4.3-2
> )
>
> This sentence is only true if the old record could have persisted after a
> change in ownership.  Evidently, the idea that records are not preserved
> across ownership transfers is not obvious to everyone.  That's why I think
> we need to make it explicit.
>
> --Ben
> ------------------------------
> *From:* John Levine <[e-mail]>
> *Sent:* Wednesday, June 11, 2025 6:28 AM
> *To:* [e-mail] <[e-mail]>
> *Cc:* Ben Schwartz <[e-mail]>
> *Subject:* Re: everything bagels, Persistence of DCV, including for
> Delegated DCV (for draft-ietf-dnsop-domain-verification-techniques)
>
>
>
> It appears that Ben Schwartz  <[e-mail]> said:
> >-=-=-=-=-=-
> >
> >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.
>
> I don't think any of this is wrong per se, but I also think it is vast
> overkill, the threats are
> largely if not entirely hypothetical, and this will add a lot of
> complication that distracts from the
> goal of this draft, to provide a consistent form for these records so you
> can tell where they're from
> and if they're likely still to be useful.
>
> For example:
>
> >3. When acquiring a zone, the new owner MUST promptly remove all VCEs
> whose function is not understood and approved.
>
> I dunno about you, but when I have bought or sold domain names, the
> transfer has never ever included a
> copy of the existing DNS zone.  The new owner has new nameservers and sets
> up all new DNS.  One time I
> persuaded a buyer to keep my MX for a while to help move mail users but
> that was a one-off and
> totally manual.
>
> While I believe that one might in theory do an on-path attack to do fake
> DCVs, unless someone can show
> some real examples I would not confuse people by talking about it.  It's
> no different from faking any
> other DNS record.
>
> R's,
> John
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>