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
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
