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

[Erik Nygren <[e-mail]>]

I've been thinking about this a bunch, and I think DCV is not necessarily
one-time and the current focus on that is counter-productive.  Instead we
should be describing what properties are present due to the persistence of
a DCV entry, especially since it is public once entered into the DNS.  This
relates to how Intermediates fit in as well.  Over the next week or two I'm
going to see if I can propose an alternate PR (or set of PRs) that may
address some of the concerns here.

In response to my objection to Paul Hoffman's PR to remove intermediaries,
Paul was asking for some specific examples of where they are used and their
need.  A concrete example is how Akamai (and likely other CDNs) handle
Default DV certs.  For example see:

https://techdocs.akamai.com/property-mgr/reference/post-certificate-challenges
https://techdocs.akamai.com/property-mgr/docs/add-hn-with-default-cert-la

In this case there's an instruction to CNAME "_
acme-challenge.www.example1.com" to "
ac.afae21b9a98d2d845d8032da0d689252.www.example1.com.validate-akdv.net" and
then the latter is automatically updated to respond to ACME challenges from
a CA such as LetsEncrypt.  This intermediate token (eg,
"afae21b9a98d2d845d8032da0d689252") is crucial as it is bound to the
customer account and configuration on the Akamai side.  eg, if example1.com
were to be transferred over to an unrelated actor, their ability to persist
this CNAME would not allow them to continue to configure anything related
with this certificate on the Akamai side.  Additionally, by removing this
CNAME (or starting fresh with a new zone not containing this CNAME) they'd
be revoking access to the previous owner of the zone and would also prevent
renewals of the certificate from succeeding.

This case is illustrative of the sorts of properties DCV can provide, and
the roles Intermediates play in it.

For ACME certificates, there is a likely need to keep refreshing the leaf
DCV entry as the desire is to associate a specific cert signing request
(CSR) with a specific refreshed DCV entry.  This is due to the nature of
the ACME protocol, but there will be other DCV applications where this is
not the case.

Another DCV model is where persistence of a DCV record implies that a
user/account to whom the record was issued continues to have control over
the domain.  Removal of the record (or not reinstalling it after a change
of domain ownership) is effectively a revocation.  But for persistent
records it is especially important that simply cloning and reinstalling the
record does not give the new owner of a domain powers.

Intermediates are a necessary way to transitively adapt between these two
models (eg, account tied with persistence and one-shot re-validation).

Being able to add and persist a DCV entry demonstrates:
   * the ability to add an entry into a domain (that then becomes public)
   * the ability to persist an entry in a domain, which could either be due
to continued control over the domain or copying a previously accessed
public record from when the domain was previously controlled

One-shot validation is needed for some applications, either where the
presence of the DCV entry (and thus the ability to clone it) has security
properties that make it no longer applicable, or for applications such as
ACME where there is a need to periodically tie DCV to some entity or
assertion outside of the DNS (eg, a cert signing).  Persistence is needed
for other applications, as changing a record at a high frequency is not
possible especially for cases where a CNAME is used to integrate with a
third-party provider.

Persistence does have risk factors that any design needs to mitigate:
* Accidental persistence.  However, forcing an operator to have to
frequently reapply the change is not a fix here as things will need to be
automated themselves in ways that add complexity and new accidental
persistence risks.
* Cloning of a public record by a new domain owner after domain transfer.
To mitigate this we need to ensure that the presence of a record by itself
is not adequate.  The validation state can not be captured entirely within
the record, but needs to be tied externally to the validated entity.
* Dangling CNAME records (especially if not DCV-specific) which could be a
problem if ownership changes in the target of the CNAME.

I believe what we have in the current draft covers many of the issues that
arise but could use better text providing context here.
I'll see what I can do to propose some alternatives to get us unstuck.

Best,
       Erik