Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Tero Kivinen <[e-mail]>]

Jan Dušátko writes:
> Scott, Barry,
> as far as I understand, SPF are historic technology, but still have a 
> reason why to use it. In my opinion (and concerns), it is also necessary 
> to be aware of the extension of the individual protection methods 
> provided by senders (amount of domains). This is not a deep analysis. It 
> is possible that the numbers given will not be accurate.
> SPF        87%
> DKIM    13%
> DMARC 63%
> ARC         5%

How were those values calculated? They are very different compared to
the actual mails going through different servers. Is this calculated
from the domains used, not from emails processed? How many emails was
used to calculate this statistics, how many domains were there in
total?

> In terms of provability, each DKIM signed email will be sent from the 
> owner of the authorized servers. Ideally, therefore, it is not necessary 
> to combine SPF and DKIM, only DKIM could be sufficient.

Yes.

> However, the following situations are a problem. As a rule,
> DKIM+DMARC is not fully implemented, part of the domains are
> protected by DKIM, part by DKIM + SPF, part by SPF only.

Thats why I think it is important that we get more DKIM
implementations for DMARC. 

> - Only DKIM and DMARC are implemented, yet the SPAM distributor sends an 
> email without the DKIM signature and without the key information.

SPAM distributors are not interesting here, DMARC/DKIM/SPF are not
protecting against spam, there is no way they could ever be efficient
for that.

If there is no DKIM signature the message is not authenticated to
originate from the domain where it claims to be, thus it will not gain
from the possible whitelisting, better reputation etc associated with
the domain.

> - Only DKIM and DMARC are implemented, and a signed email is available. 
> The SPAM distributor starts repeatedly sending the same email 
> (equivalent to a DOS attack).

It is very easy to filter identical emails, especially when they are
actually signed with same dkim signature, thus you can safely mark
later emails as duplicates, and not deliver them to mailbox.

I do not think there is ever need to deliver duplicate emails to same
mailbox, thus you can safely remove them.

If the RCPT TO is different than the To-header inside the body, that
is one of the checks that spam checking software quite often use to
check whether the email is spam. I.e., if the To-header does not have
actual address of the mailbox the message is supposed to be delivered
to, then give some positive spam points to the message.

If this is forwarded email (i.e. the to-address contains something
like [e-mail], instead the address where my emails finally gets
forwarded to) then the user who set up the forwarding most likely
already added those addresses as "valid recipient addresses" to their
mail settings, thus forwarded emails do not get marked as spam.

And of course if thousands of different mailboxes in your system are
getting same DKIM signed message, and some of the users start marking
it as spam, that is good indication that others are too, thus your
spam checking software can learn from that and start processing those
emails differently. 

> - Only DKIM and DMARC are implemented, and a signed email based on 
> RSA+SHA1 is available. Because it is possible to find collisions for 
> SHA1, and the digital signature is actually an "encrypted hash," it is 
> possible to send counterfeit mail with a signature that looks genuine. 
> The solution is to use explicitly h=sha2, but if not specified, it is 
> also possible to "downgrade the signature" against another key on this 
> domain supporting SHA1 (any SHA1-based signature will be used).

In stackexchange there was question about this:
https://crypto.stackexchange.com/questions/99767/how-easy-is-it-in-2022-to-find-a-sha1-collision

The first answer was that using single GPU it would take about 5.3
years to find collision (year 2022). Getting 30 GPUs would drop that
to 2 months, and those GPUs would cost about $20k, and the electricity
for those GPUs would cost you about $2k for 2 months.

Using AWS it would still take months and cost you few hundred dollars.

And you need to do that for every single email you want to
counterfeit.

For phishing attacks this would be feasible, i.e., if you want to take
real email from the CEO, change it and find collsion and send it
forward taking few months and costing hundreds or thousands of dollars
would be ok.

So companies who actually care about the security in DKIM should NOT
USE SHA1. For spammers this is not a feasible solution. Also if you
are using unsecure crypto parameters for DKIM (short keys, broken
hashes) you should also change those keys every now and then...

> These attacks are the first that came to my mind. How we can mitigate 
> that threat? According to owner authorization of IP addresses, they 
> protect against a different kind of attack than the digital signature by 
> using DKIM.

You did not describe any threat the DMARC/DKIM/SPF is actually trying
to protect against. They are not trying to say whether the content of
the email is good or bad, they are trying to say whether it was sent
by the domain that they claim to come from.

> On the other hand, SPF can bring beside of advancing security particular 
> security reduction. Simply because most of services are "shared in 
> cloud" right now. Cloud service providers generally provide the extent 
> to which virtual services can operate. It is not a question of who has 
> or does not have the ability to use the service (in meaning that service 
> are approved to send e-mails beside of domain). In this case, it is not 
> a problem to create a system in the cloud technology that starts mimic 
> and send junk mail instead of an authorized organization. The methods of 
> correction are reactive, so it will take some time before such an attack 
> is detected and mitigated. However, even a limitation of scope can be 
> supported by DKIM, as it limits the space from which an attacker can 
> operate.

In iki.fi we run graylisting based on the blacklisted domains. Quite
often big companies email servers end up in those blacklists, and gets
graylisted. This seem to happen very often for services that send one
time email tokens for logins or password changes etc. As those emails
have ridiculously short lifetime (5 minutes or so) there is no way the
actual email gets through iki because of the graylisting.

Almost always those ip-addresses are in some of the cloud services,
and my guess is that those email servers did not end up in blacklist
because they did something wrong, most likely it is shared or recycled
ip-address that they got in cloud.

This is so common, that nowadays I always request those emails half a
dozen time (just to teach graylisting servers for all possible
ip-addresses of senders) and then wait for half an hour so the emails
gets through (which are useless as they are already expired), and then
ask for one more which usually gets through as now graylisting knows
those ip-addresses are real mail servers.

So sharing of the ip-addresses or recycling them in cloud seems to be
very common. 
-- 
[e-mail]