Thank you for laying out your vision. Many of the readers of standards documents aren’t at the same level as the WG (such as myself). I’m someone who will need to grok all of DMARC bis so, in a sense, I represent a set of your audience. So I have an interest in a standards document that’s as clear and explicit as possible. As complicated as it needs to be and no more. This probably goes without saying.
I’d like to see more of what you just did which moved the ball forward, IMO.
Neil
> On Nov 25, 2022, at 5:53 AM, Douglas Foster <[email protected]> wrote:
>
>
> DMARC requires an evaluator to trust the design, but we lack a cogent statement of the theoretical basis for doing so. Here is my proposed language:
>
> "The RFC5322.From address is not directly verifiable. DMARC addresses this problem using proxy verification: The From address is considered verified using the combination of a verified identifier and a meaningful relationship between the verified identifier domain and the RFC5322.From domain."
>
> Discussion
> This language identifies the two axioms on which DMARC is built:
> - a verified identifier, one of:
> RFC5321.MailFrom verified by SPF PASS or
> RFC6376 DKIM "d=" domain, verified by DKIM PASS
> - a meaningful relationship
> Same Organization
> Which includes the subtypes of:
> same domain
> parent authenticates child
> child authenticates parent
> sibling authenticates sibling
> These are chosen because they have broad applicability, such that reputation knowledge about the identifier is not required to produce a meaningful result.
>
> Like any heuristic, DMARC will sometime produces results which encourage a disposition different than what the evaluator wants, typically suggesting distrust when trust is intended. This requires alternate verification strategies, but our core documents have not explained how exceptions should be handled, and a best practices document is not yet started. Therefore, it is worth examining how alternate authentication can be achieved by altering the axioms:
>
> Alternate identifiers could include:
> ARC Set "d=" domain validated an intact ARC set
> Server host name validated by forward-confirmed DNS
> Sender header domain validated by DKIM signature
>
> Alternate relationships include:
> "Vendor to Client" -- the From domain is trusted to have a client relationship with the validated domain
> "Delegated authenticator" -- The From domain is trusted to have been successfully validated by a previous server
> "Trusted impersonator" -- The validated domain is trusted for impersonation because it only impersonates for beneficial purposes on behalf on an individual domain account.
> "Trusted infrastructure" -- The validated domain is trusted to not impersonate
>
> There may be other identifiers and relationships that could be imagined. None of these alternatives can produce general solutions, because they require knowledge which is external to both the message and the DNS. However, these methods do provide the basis for local policy to address situations where authentication is needed but DMARC cannot produce PASS.
>
> ARC provides proxy validation using the combination of the ARC Set's "d=" domain identifier, the ARC Sets authentication results, and "Delegated Authenticator" as the meaningful relationship
>
> A website or organization which is known to impersonate, but only for beneficial purposes, can be validated using the server host name, verified by fcDNS, and "Trusted Impersonator" as the meaningful relationship.
>
> Proposals to use Sender as the alternate identifier have failed for two reasons: (1) by trying to create a general solution rather than a local-policy solution, and (2) failing to provide an alternative to "same organization" as the meaningful
Sir, your knowledge of this domain is clearly deeper than I could ever achieve so it’s with deep respect that I acknowledge that I don’t grok what your highest priority is in terms of the standard. That is, what’s the highest priority problem and solution with solution defined as wording to be added to or changed in the document addressing the problem?
Neil
|
