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

[Erik Nygren <[e-mail]>]

There's an extensive discussion in
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/160
on the purpose and nature of DCV which seems more appropriate to bring to
the list rather than keep in github.

A few fundamental parts of this seem to be:

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?

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?

3) When there is an ongoing validation of control (whether for direct DCV
or Delegated DCV), how do we make it robust against risks such as dangling
CNAMEs?
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)?
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?
4d) How do we avoid domain takeover risks from dangling CNAMEs which
require that the target of a DCV or Delegated DCV be bound to either a
validation instance or to an account/entity requesting validation?

5) How do constraining records (eg, CAA is the one defined) interact?

We should certainly call these out in a way that is consumable, but also
provide recommendations.  I disagree with the Ben's PR that just saying
"DCV is point-in-time" is a solution.

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.  The only one of these they don't address is 4a (ie,
providing context to a domain operator for operational reasons).
Unfortunately that context is inherently sensitive so conflicts with 4c.
Keeping it in a comment in the zone file might be one recommendation but
isn't really standard.  (If we had a way to keep non-public comment
metadata in zone files that couldn't be queried that would be great, but
outside the scope of this draft to solve.)

For constraining records (eg, CAA) we had decided previously to keep them
separate and out of this draft.

My proposal/recommendation would be to not incorporate Ben's PR (
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/160)
but instead to make sure we cover the whys for this.

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).

Best, Erik