On Thu, Oct 31, 2024 at 8:28 PM Ben Schwartz <bemasc= 40meta....@dmarc.ietf.org> wrote:
> This is why I wanted to raise this topic. I don't believe we have thought > very carefully about when DCV is actually safe or appropriate, and I don't > think we should be recommending a mechanism without consensus and guidance > for what this mechanism achieves and when this mechanism is safe to use. > > In the case of both Google Mail and Office365, the customer is free to > delete the verification TXT record after the verification step is > complete. And yet these systems treat this verification step as > permanently binding the domain to an account in their system. Depending on > your threat model, this might be perfectly reasonable or obviously > vulnerable. I don't think this document should move forward without > providing clear guidance on this key question. > > If these providers did what you are suggesting, they would be in violation > of recommendations in Section 5.7, which says that "a new challenge needs > to be issued" every time the ASP checks the verification record. But this > is also strange: common sense suggests that I could leave a record in place > to indicate my continuing consent. That is true, but such a record is no > longer providing Domain Control Validation; instead, it is performing > authorization (like MX), and is outside the (present) scope of this draft. > Why is it strange? The application provider is verifying domain ownership based on a secret challenge that was privately communicated to the domain owner. If they want to subsequently re-validate domain ownership, they can't re-use the previously communicated challenge without security issues. The challenge is now disclosed in the global DNS and was visible to anyone, the domain's ownership may have changed hands, and the new owner may have just copied the old challenge record into the new zone they manage. I think the draft needs to point this out. Yes, some applications may be using some long term authorization action based on a one-time domain control validation action, and that may be creating a security issue, but that is out of scope of this draft (in my opinion). Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
