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

[Paul Wouters <[e-mail]>]

On Tue, 6 May 2025, Ben Schwartz wrote:

> ____________________________________________________________________________________________________________________________________________________________________
> From: Erik Nygren <[e-mail]>
> 
> > 1) Is DCV just point-in-time validation of control or does the continued presence of a DCV record an ongoing assertion of validation intent?
> 
> Ultimately, deployments can do whatever they want here.  The question is, what is the BCP for the meaning of an "old" DCV record, since it clearly means something
> very different from a "fresh" record.
> 
> I think the answer is "nothing".  Otherwise, we are proposing to mix two different meanings into this record, making it much harder to say what DCV is.

Older versions of the draft had a human readable expiry time on the
record to help with this exact problem, but people thought it was
too complicated. It might still be the bets way forward to
introduce something like that. Or at least say, if you are mixing
these two types of records, clearly indicate this in the RDATA.
Section 4.1.2 describes how to add token meta data. Perhaps we
can make this more explicit?

> > 2) How does Delegated DCV fit in here, where by definition of the use-case its continued presence is an ongoing assertion of validation intent to allow an
> intermediary to perform recurring but more time-limited revalidations?
> 
> I believed a Delegated DCV CNAME means "I authorize this other domain to perform DCV on my behalf".  It is a persistent authorization, not a proof of control.
> 
> > 4) How do we balance some conflicting considerations?
> > 4a) For persistent records, allowing the domain owner to know when they are safe to remove (and when they are still being relied on)?
> 
> Make their purpose evident from their contents.  Who is authorizing whom to do what?

See above.

> > 4b) How do make persistent records safe to be persistent (eg, not derived from any secret that needs rotation)?
> > 4c) How do we avoid putting sensitive information (or anything derived from sensitive information) into the DNS, such as account names or account identifiers?
> 
> I think these identifiers can reasonably be "obfuscated" where necessary without issue.  The important thing is that they be clearly distinguishable from "ephemeral
> DCV" records, ideally with a different format reflecting their distinct purpose.

Same here, see above.

> ...
> 
> > Using high-entropy tokens (as in the current draft) with no confidentiality requirements or semantic meaning seems like the safest approach for cases where the
> continued presence of a DCV record is an ongoing assertion of validation intent.
> 
> Note that CAA records could easily have been implemented in this way, resulting in improved "confidentiality" by not revealing which CAs are approved.  Instead, the
> ACME group decided to make them human-readable.  I think this was a wise decision that would also be appropriate in many other contexts (though perhaps not all).

In their case, the information is already revealed in the current
certificate, which also shows which CA is in use. Obfuscating
vendors, while still allowing a DNS admin to recognise who the
record belongs too and whether it is safe to remove are conflicting
properties.

> ...
> 
> > As part of this we would *NOT* specify that DCV is only a point-in-time protocol, but to clarify what is needed for it to safely be used as a persistent
> validation (which is something that the ecosystem is likely relying on, as re-validation doesn't scale in all cases and will just regrade to validation not
> happening).
> 
> Persistent validation of what?  Old DCV records don't prove control of the domain.  They might prove something else though...

I don't think we can get DNS admins to go through all their DCV records
each month to manually update them to indicate continued service
consumption. The reality is that DCVs are re-used as continued
endorsement records. I don't think the draft should try and force
users into monthly manual actions - it will simply be ignored.

Paul