This problem means that I must evaluate the whole received chain to fully protect my users from impersonation. This is a big shift from my former assumption that evaluating receive-time data is all that is necessary, and is also all that is useful since header data might be forged.
I view the proper goal of this undertaking should be to provide evaluators with guidance and tools that will help them evaluate more accurately. That effort should start from an understanding of the threats that exist. I would have hoped the scope would have included (1) impersonation threats when DMARC policy is absent or P=none, (2) preventing false rejects caused when evaluators treat a DMARC result as a certainty rather than a cause for investigation, and (3) preventing false acceptance based on credentials upgrades, and (4) navigating from detectabke threat message to detectable threat source. In IETF norms, that is likely more than one document. I learned that the group has never embraced that scope, and is settling for something much less important, which is why I asked to have my name removed from the document I am reporting what I am learning as I learn it. The group can use the information as they see fit. I think there is a big distinction between "Sender identity is confirmed but sender may be malicious" and "Se in det identity appears to be confirmed but is actually not confirmed." Doug On Thu, Sep 12, 2024, 10:25 AM Murray S. Kucherawy <[email protected]> wrote: > Are you proposing a text change? Working Group Last Call closed some time > ago. > > On Thu, Sep 12, 2024 at 4:29 AM Douglas Foster < > [email protected]> wrote: > >> A DKIM signature acts like a notary public, "This person, who is well >> known to me, can be reliably associated with this document." >> > > How does this apply to very large operators like Gmail? Are you not > asserting that they need to establish "well known to me" somehow across > millions of users? What do you expect that would look like? > > >> Signing works for DMARC only when the DKIM signer has actually validated >> the entity before adding the signature. >> > > I would argue that the value of a DKIM signature increases when receivers > have confidence that what they sign is desirable (or rather, not > undesirable). This is "reputation". > > Therefore, when a signature is applied by an outbound gateway server, >> everything depends on whether the gateway was able to authenticate the >> message being signed. I know of no discussion about how a gateway >> authenticates its clients and how an evaluator knows that the signature was >> applied to an authenticated message. >> > > I would argue that this is out of scope for DMARC. It's enough to observe > that a DKIM signature is not an attestation of the value of the message, > only a statement that the signing domain handled the message (directly or > by proxy). This is discussed in Security Considerations of the DKIM > standard. > > More generally, a message should only be considered DMARC-validated if it >> can be validated at every organization change. There are many obstacles to >> making that determination. ARC is clearly part of the solution. >> > > If a message has a valid author signature but is not signed by any > intermediary, what's missing from a usable DMARC evaluation? > > -MSK >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
