Improve default behavior about which Authentication-Results are trusted when enabling ARH reading globally

[ell1e]

Setup for the bug: Because I use automatic PGP on unencrypted incoming mail provided by the paid e-mail provider I use, I have to disable DKIM checking through the addon itself because the automatic encryption breaks the signature. I therefore have to rely on DKIM Verifier displaying the results of the "Authentication-Results" headers for me. My usual developer e-mail is forwarded through a custom SMTP that I run that adds DKIM check results, and then ends up at an SMTP by a standard paid e-mail provider that also adds DKIM check results before applying Auto-PGP. You can see both of these Authentication-Results headers in the chain below, the lower one being from my forwarder SMTP.

Expected result: As soon as DKIM Verifier finds any Authentication-Results headers somewhere in the entire chain that say "dkim=fail" or "dkim=none", even if that may also trigger on a spoofed fail result attached by the sender to the return path, that should lead to a fail being displayed.

Actual result: As soon as the top-most Authentication-Results header is present and mentions DKIM, DKIM Verifier seems to display "Valid", even if that very top-most header says "fail". This is with local DKIM check disabled, due to above reasoning.

[lieser]

The expected result you describe it pretty much the opposite form the current intentional behavior, which picks the most "valid" one to show.
I'm also unaware that the RFC describes such a behavior as you want.

If you want to have more control over which Authentication-Results header (ARH) is used take a look at https://github.com/lieser/dkim_verifier/wiki/Account-Options#trusted-authentication-servers.

Of course if all ARHs contain a fail result, the add-on should not make a valid result out of it.
Could you send me one affected e-mail as a saved eml file to [email protected] (or at lest the complete headers)? Would make it a lot easier to figure out what is going wrong. If you don't have an email you would be willing to share with me we could also try to see if the debug logs are enough.

[ell1e]

What I proposed is the most defensive default behavior I could possibly think of, in case no specific server is marked as trusted. I think that would make the most sense if no server is marked as trusted to fail on whatever fail/none is found anywhere in the chain, since then an attacker could at best only mark themselves as failed (which seems like a bonus if they do, if anything).

[ell1e]

I did some more testing, and for my work e-mail a few hours ago I made the change of making my SMTP strip any external "Authentication-Results" headers which works splendidly as a fix for this. It prevents the addon from picking up any untrusted external headers. However, for my private e-mail I don't have that sort of access to the SMTP server, so it would be nice if in such a situation the default behavior was safer.

[lieser]

Thanks for providing me the e-mail. Like you noticed yourself already it contained a third ARH that did not show up in your screenshot, where the add-on did pick up the valid result from.

I totally agree that the current default behavior could be considered insecure. If one is concerned about such attacks the already mentioned trusted authentication servers needs to be configured for each account!
As the RFC requires the servers to strip any ARH result with it's own server-id, this should ensure you see only ARH from your server.

I choose this default because I fear for many it is to complicate if they need to configure this id.
My admittedly a little weak justification for this suboptimal default behavior (from a security perspective) is that that I'm not aware of ARH spoofing being widely used as an attack.

I will think more about your proposal, like you may have noticed I'm currently not yet that convinced of it. In some cases (especially for SPF, but also DKIM with e.g. mailing lists) and under the assumption the ARH header is not spoofed, I could imagine cases there one would like to see the more valid result of an earlier ARH (this of course would be best combined with ARC #87).
And your proposal would not prevent attacks in all cases, at least as long ARH reading can be enabled globally. Currently you could have two accounts, account A adding ARH, but the other account B not. If now one does not take the effort to enable ARH reading just for A, ARH spoofing would still be possible with your proposal for B.

One better default behavior I have been thinking about is trying to guess some reasonable default for the allowed server id from the configured server domain or e-mail address of the account.
But I imagine this maybe to often resulting in a server id that does not match the correct one.

[ell1e]

And your proposal would not prevent attacks in all cases, [...]

While that is true, it might be pretty safe when ignoring any Authentication-Results that contains any DKIM info other than dkim=none if there isn't actually a DKIM signature. Then you'd cover the common case where at minimum one trusted intermediate SMTP checks DKIM but only inserts headers when there was DKIM present.

it is to complicate if they need to configure this id.

It may not need to be, since I think the only "attack" might be an intermediate intentionally(!) trying to make DKIM incorrectly fail, which seems unproblematic. And just guessing a server id seems less safe than failing on any dkim=fail or dkim=none found. My apologies if I'm missing something, however.

[ell1e]

For what it's worth, I just confirmed from digging in my mails that one of my accounts uses multiple subdomains to add in the Authentication-Results header. Therefore, unless it is configured to strip out all other subdomains which I assume it may not be, it's not possible to set a guaranteed safe set of server ids. However, failing on any dkim=fail or dkim=none should be safe for my config if I'm not mistaken, since all my accounts have a trusted SMTP at the top of the chain that will add the failure whenever applicable.

[ell1e]

The problem I see with setting multiple hosts A, B is that perhaps an attacker could simply add a fake Authentication-Results header with host B, and the provider host A would perhaps only filter out host A, wouldn't it? So it seems to me like multiple hosts is inherently prone to tampering, while simply failing on any fail isn't. I might be misunderstanding this, however.

[lieser]

I think I now understand what your concern is with setting up a secure manual configuration.

• Your e-mail: [email protected]
• Your mail provider/mail server configured in Thunderbird is: example.com
• example.com used multiple Mail Transfer Agents (MTAs) that add ARHs with different authserv-id: authserv_1.example.com, authserv_2.example.com.

Now if you would configure as trusted authserv-id both authserv_1.example.com and authserv_2.example.com, you are worried if your provider example.com will always remove ARHs from both authserv-id it uses regardless through which MTA it was processed.

The I think relevant parts from the RFC are https://www.rfc-editor.org/rfc/rfc7001#section-1.2, https://www.rfc-editor.org/rfc/rfc7001#section-1.6, https://www.rfc-editor.org/rfc/rfc7001#section-2.4 and https://www.rfc-editor.org/rfc/rfc7001#section-5.

The RFC does not explicitly state what must happen.
But I think the intend is clear: all MTAs from the example.com provider should be in one Administrative Management Domain (ADMD), in this case example.com. When receiving a message from outside containing an ARH, all ARHs with an authserv-id ending with the example.com domain should be removed, meaning where is no security issue of trusting both hosts.
Anything else I would consider bad practice by the mail provider.

---

Now if you are talking about wanting to trust multiple authserv-id from different ADMDs:
Unless you can guarantee that messages will always pass through both ADMDs, and no untrusted MTA comes after the message goes through a ADMD:
Yes you are correct, a targeted attack would be probably possible.

But I fail to see how your proposal would help in this case.

---

Now don't get me wrong, your proposal works as a potential better default to the current one of simply trusting all ARHs.

All the above is about if your proposal could also improve the security over the already possible manual configuration.
Currently I fail to see this, at least under the assumption that the trusted hosts follow the intend of the RFC.

[ell1e]

Now don't get me wrong, your proposal works as a potential better default to the current one of simply trusting all ARHs.

Yes I agree. While I have some thoughts on the multiple hosts of same provider situation, I don't think it's super relevant due to this point. Users who don't trust their provider to filter out things properly for such a multi domain situation can then just stick with the fail on any failed header default.

Edit: for what it's worth, my thoughts are if the RFC doesn't explicitly state this multi host handling, I don't trust the providers to do it. OpenDKIM for example doesn't have the greatest defaults either if you ask me, and this seems like a slightly arcane problem to be aware of. So I'm pessimistic about providers being aware.