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

[Ben Schwartz <[e-mail]>]

Some answers from my perspective.

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

> 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?

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

...

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

...

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

--Ben