Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication

[Scott Kitterman <[e-mail]>]

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 “([e-mail]” 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=([e-mail]; receiver=[e-mail])

While this is not ideal (for envelope-from=([e-mail].  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