On Thu, 31 Oct 2024, Ben Schwartz 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.
If that is so, that didn't use to be the case. A quick googling finds:
https://learn.microsoft.com/en-us/answers/questions/688596/app-service-custom-domain-mapping-can-we-delete-tx
Which recommands leaving the records in to avoid "subdomain takeover".
Another example is auth0:
https://community.auth0.com/t/can-i-delete-dns-txt-record-after-verification/122288
Which also tells you to not remove the record.
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.
The goal of the document is to present better ways to use DCV that does
not endanger or hamper or litter the DNS and DNS protocols. I still
believe when or whether to use domain control verification is out of
scope. It might be useful as its own separate document.
That is, the goal is to ensure people don't cause huge APEX issues with
records they cannot identify to who they were for or whether these can
be removed.
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.
It does both.
Basically, I think we have some work to untangle the purpose of DCV in the
current text.
I still dont think the document should consider the use of the
mechanism, just proper implementation of the mechanism. Like
"this is how you use a lock" and not whether or not you should
add this lock on that door or not.
The document targers basically programmers that are not DNS experts.
I'm reluctant with adding more complicated wording which will just
lead to implementers to stop reading and start hacking. The original
goal was a simple "dont do APEX please" and already spiralled out of
control quite a bit. I am concerned the document is getting too wieldy
for programmers to read and use as guidance already.
But let's see what my co-authors and other WG participants say.
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
