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