On Wednesday, April 22, 2020 4:28:44 PM EDT Dave Crocker wrote: > > 4.1 HELO/MAIL FROM confusion > > This seems to imply that tightening is needed in DMARC, so that it uses > an SPF domain that SPF has actually been validated? I think the issue is > that SPF validation needs to inform DMARC what domain it has validated, > rather than have DMARC decide which domain to fetch.
The standard authentication results header field will do this in the form of: Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=example.com > > SPF implementations treat “([email protected]” as anempty MAIL FROM > > address, and thus forward the resultsof checking HELO to the DMARC > > component, because thestring in the parentheses can be parsed as a > > comment ac-cording to RFC 5322 [10]. Some DMARC > > implementations,however, may take it as a normal non-empty address, > > 1. This issues goes away if SPF supplies DMARC the domain name, rather > than DMARC having to fetch it > > 2. I doubt this otherwise needs changes to language in the DMARC spec, > but it's worth making sure. I agree it's worth making sure. The input for DMARC from SPF/DKIM should a both a result and a domain. There is some inconsistency in how SPF verifiers report SPF results when using HELO as a fallback for an null Mail From. RFC 7208 section 2.4 is, IMO, reasonably clear that for a null Mail From, the SPF 'Mail From' identity is postmaster@[HELO], so it should be reported as an smtp.mailfrom= result, which the paper claims is the threat vector. I think they are wrong. As long as the input domain is checked and is in alignment for DMARC, there's no issue there. I tried their exact scenario with two of my domains and here's what the SPF verifier reported: Authentication-Results: mx.example.org; spf=pass (sender SPF authorized) smtp.mailfrom=kitterman.com (client-ip=72.81.252.18; helo=kitterman.org; envelope-from=([email protected]; [email protected]) While this is not ideal (for envelope-from=([email protected]. The string should be quoted [per the 5322 CFWS definition], it shouldn't lead to any confusion about the identity. I figured out this is wrong and the example below is right per various RFCs, but it took some investigation to dig it all back up. A more thorough review by someone that knows more than me would surely be a good idea. > > 4.3 Authentication results injection > > Another focus on what results are communicated and how. > > The paper asserts that AR is used as DMARC input. I suspect that is > rarely, if ever, true. Yes? No? For integration of open source components such as opendkim and opendmarc, this is the standard method of communicating results data between components (also true for communicating SPF results to opendmarc is you don't use its internal SPF implementation). For what it's worth, I invested some time yesterday and today testing the various open source components I maintain (pyspf, pyspf-milter, policyd-spf- python, dkimpy, dkimpy-milter, and authres) and found some behaviors in the cases they describe that is sub-optimal, I could not replicate any of the security relevant issues they describe. I did get some new test cases. ... As an example, if the example they used is presented to the authres module as the d= domain in for a DKIM verification, d=legitimate.com(.attacker.com, it returns d="legitimate.com(.attacker.com" [note the quoting, which is correct per the 5322 CFWS definition]. If it's parsing that, it fails to return a domain at all, which is a bug, but doesn't cause the reported problem. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
