Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:


This tactic appears to me to have three problems: (1) negative 
reputations are of little value to receivers, because attackers can 
easily shed them; (2) if I have to remember everything with a negative 
reputation for some undetermined period of time, I now have a resource 
problem; (3) I can just not sign my mail, because maybe no reputation 
is better than a negative one.


I don't understand #1. As in they can move to another service? Or what?

As for 3, it's pretty easy to cons up a new domain with fresh neutral 
reputation and still enjoy the supposed benefit of mail being signed for 
awhile. If you factor SPF in though it probably gets harder because now 
you need not only a new domain, but the underlying network connectivity 
to avoid detection.


Which brings up a question: even though they pass on DKIM they should 
fail on SPF, right? For transactional email that seems like a big old 
red flag, right?




In contrast, positive reputations are far fewer in number, far more 
valuable to collect and protect, and very likely last a lot longer.  
Giving preferential treatment to a domain that earns a positive 
reputation seems like a much better approach.


In both cases you need to keep track of both as somebody with a bad rep 
might get better and one with a good rep might get worse, right? That 
is, this isn't static. Preferential of course is pretty subjective. I 
suspect that most of these filters operate much like spamassassin which 
gives weights to various factors, so good and bad are both useful.


Mike

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/13/22 9:06 AM, Evan Burke wrote:



On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton  wrote:

This is interesting and surprised me a bit. I had expected that
the senders of the messages being replayed were the large consumer
mailbox providers, because it would be easy for spammers to hide
in a large crowd and because the reputation of the large mailbox
providers is (I expect) fairly bullet-proof just because of their
size.


I can't speak to whether large consumer mailbox providers' signatures 
are getting replayed, but with the scale of replay spam we're talking 
about - on the order of billions per day, at its peak - that's 
probably enough to make a difference in reputation for even the 
largest MBPs.


So if they are sending billions of piece of spam within minutes, say, of 
getting a piece of mail signed, I don't know what this working group can 
do about this. Signatures definitionally need to be valid in transport 
time. And the notion that MDA's stripping the signature doesn't work 
either since they'll just send to one that doesn't.


I've always been really skeptical about calling these things "replays" 
because that is a perfectly valid use of email. The only difference 
between legitimate and illegitimate is the content which IETF can't 
address. There may well be mitigation but that seems well out of the 
scope of a standards body like IETF (MAAGW otoh, might be a good venue).


Mike___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton  wrote:

> This is interesting and surprised me a bit. I had expected that the
> senders of the messages being replayed were the large consumer mailbox
> providers, because it would be easy for spammers to hide in a large crowd
> and because the reputation of the large mailbox providers is (I expect)
> fairly bullet-proof just because of their size.


I can't speak to whether large consumer mailbox providers' signatures are
getting replayed, but with the scale of replay spam we're talking about -
on the order of billions per day, at its peak - that's probably enough to
make a difference in reputation for even the largest MBPs.


> Is there anything that you can say about the types of domains whose
> reputations are suffering as a result of replay attacks? Are they, for
> example, small consumer mailbox providers, email sending providers, or
> services that for some reason allow third parties to send (presumably
> transactional) email through their servers?
>

Predominantly ESPs, but really anyone with substantial sending volume and
good reputation on the d= domain. ESPs seem to be the primary target
because they tend to have the highest sending volume, so the attacker can
send more replays before reputation and deliverability degrade.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Jim Fenton]

On 12 Dec 2022, at 12:11, Evan Burke wrote:

> These attacks were very narrowly targeted; the vast majority of DKIM replay
> spam this year has been sent to just a few of the largest consumer mailbox
> providers. In that context, lack of awareness of the problem is a poor
> argument against trying to solve it.

This is interesting and surprised me a bit. I had expected that the senders of 
the messages being replayed were the large consumer mailbox providers, because 
it would be easy for spammers to hide in a large crowd and because the 
reputation of the large mailbox providers is (I expect) fairly bullet-proof 
just because of their size.

Is there anything that you can say about the types of domains whose reputations 
are suffering as a result of replay attacks? Are they, for example, small 
consumer mailbox providers, email sending providers, or services that for some 
reason allow third parties to send (presumably transactional) email through 
their servers?

-Jim

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Tue, Dec 13, 2022 at 2:54 AM Alessandro Vesely  wrote:

> Perhaps they could devise better methods than asking _accountable? (Y/N)_
> on a
> questionnaire.  Linking to bank accounts is an example.
>

Would you link a free email account to your bank account for any reason?  I
don't think I would.  I'll go somewhere else.

A discernment possibility is to sign differently.  RFC 6376 specified an
> Agent
> or User Identifier tag, i=, as a finer grained identity.  One having
> i=bullshit...@example.com would still be a valid DKIM signature.
> Alternatively, could use subdomains, d=bullshit.example.com.  How long
> would it
> take receivers to learn it?
>

This tactic appears to me to have three problems: (1) negative reputations
are of little value to receivers, because attackers can easily shed them;
(2) if I have to remember everything with a negative reputation for some
undetermined period of time, I now have a resource problem; (3) I can just
not sign my mail, because maybe no reputation is better than a negative one.

In contrast, positive reputations are far fewer in number, far more
valuable to collect and protect, and very likely last a lot longer.  Giving
preferential treatment to a domain that earns a positive reputation seems
like a much better approach.

-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Mon 12/Dec/2022 15:50:44 +0100 Laura Atkins wrote:

On 12 Dec 2022, at 14:34, Murray S. Kucherawy  wrote:

On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely mailto:ves...@tana.it>> wrote:
The alternative is to say: Well, if you can't make at least one of those 
two quantities bulletproof, then don't sign your mail.  That, though, 
sounds a lot to me like tossing DKIM in the bin.


On the opposite, if Gmail restricted signing to accountable users only, its 
signatures would gain value.  If they started doing so it would soon be 
noticed, and signatures would acquire a meaning in delivery decisions.


Is the cost of imposing a program that vets every user comparable to that of 
the damage caused by this attack vector?  My impression is that it is not.


I’m not aware of Gmail being a significant victim here - although it’s possible 
they are.



I'm not aware of their taking any significant measure (after the effort, a few 
years ago, to reorganize all the different accounts on their different 
platforms.)  Yes, security has a cost.  Why are banks insisting on 2fA?



Endowing signatures with a significant value increases the overall value of 
DKIM.


Presumably they already have significant value.  That's why this attack works 
already.


They’re an identity of a known sender that invests time and resources into 
building and managing their reputation. Google? Maybe not. But the email 
service providers who do a lot to keep the spammers off their network are a 
common victim. These spammers know that they get better delivery if their mail 
is signed by the email service provider. The email service provider’s detectors 
and defenses are enough to stop the spammer from being able to send through the 
ESP. So the spammer sends one email to an account they own and takes a 
reputation they’ve already been told they shouldn’t be using.



I guess you refer to the same incident you touched on a few threads ago.  Did 
it happen more than once to the same ESP?  To more ESPs?  Cannot (did not) they 
configure their DKIM filter to not sign for untrusted prospects?




A DKIM signature is an identity. That identity has a reputation. Attacks that 
borrow the identity belonging to senders with good reputation benefit from that 
reputation. It’s not about any DKIM signature. It’s not about a random DKIM 
signature. It’s about a known entity. Even if Gmail only signed mail from 
accountable users, there is still the possibility of spammers posing as 
accountable users.



Perhaps they could devise better methods than asking _accountable? (Y/N)_ on a 
questionnaire.  Linking to bank accounts is an example.


A discernment possibility is to sign differently.  RFC 6376 specified an Agent 
or User Identifier tag, i=, as a finer grained identity.  One having 
i=bullshit...@example.com would still be a valid DKIM signature. 
Alternatively, could use subdomains, d=bullshit.example.com.  How long would it 
take receivers to learn it?




The whole idea of a DKIM replay attack is that this is mail that cannot be 
directly sent through the infrastructure of the domain owner. That, itself, 
implies the domain owners are doing quite a bit to stop the spam from coming 
out of their network. If they weren’t doing a good job then replay attacks 
wouldn’t be happening - the mail would just be sent over that network directly.

Asking for the domain owners to “stop sending spam” when the whole replay 
process indicates they are stopping spam out of the networks they control seems 
a bit of a non-starter to me.



The securing activity you describe certainly has non-negligible costs.  Then 
why do we abhor the cost of classifying users?


Most likely, DMARC was branded as a requirement for email security and DKIM 
came as a consequence, without worrying too much about what is being signed. 
Replay attacks found the weak point of that paradigm.  Don't allow guests into 
secured areas of your premises.



Best
Ale
--






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Taking Responsibility

[Steve Atkins]

> On 13 Dec 2022, at 06:02, Evan Burke  wrote:
> 
> 
> On Mon, Dec 12, 2022 at 8:49 PM Murray S. Kucherawy  > wrote:
> At a recent meeting where I heard some mass senders talk about this problem, 
> the use of "x=" as a mitigation technique was raised.  I was curious to know 
> what their experience was in terms of (a) success overall, but also (b) how 
> broadly they found "x=" to have been properly implemented by receivers.  I 
> have to admit that was some months ago and now I forget the answer; maybe 
> someone else who was there can fill in that blank.
> 
> But I'm not sure that "x=" by itself is enough, given that it takes only a 
> matter of seconds for the attack to succeed, and it seems unlikely to me that 
> the "t=" and "x=" values would ever be that close together.
> 
> 
> x= is indeed the most effective single defensive technique for many affected 
> senders whose signatures are getting replayed, but yes - in practice it's 
> still "not quite enough" even when combined with multiple other mitigation 
> techniques. That's why we're here; existing solutions come up short.
> 
> I can't speak to support for x= broadly, but as mentioned earlier these 
> replays were almost exclusively targeted at end recipients at certain large 
> mailbox providers, and I can confirm those have proper support for x=.

If people are seeing DKIM replays we should have data on the delay between the 
mail originally being sent, and it being replayed?

Cheers,
  Steve___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim