Re: [Ietf-dkim] Misuse of antiforgery protocols
On 12/16/22 5:42 PM, Evan Burke wrote: On Fri, Dec 16, 2022 at 3:29 PM Grant Taylor wrote: Perhaps it's my ignorance, but I don't see us approaching, much less getting better than 99.9% accuracy. And let's be honest, in any other field, 99.9% accuracy is really good accuracy. To clarify: my point was not "99% is not good enough". My point was - 99% effective ESP defenses in normal scenarios end up completely ineffective for replay scenarios, IF you measure based on volumes of spam sent. When a single message turns into 100 million replays, attackers can justify spending a lot of time and effort to get that 1 message out. At this point, I have to ask what you think this wg can do about it. All of the solutions I can think about are completely out of scope of IETF. If you're trying to get amplification to make receivers do something you're probably going to be disappointed because IETF is very experienced at pushing on string to no effect. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On Fri, Dec 16, 2022 at 3:29 PM Grant Taylor wrote: > > Perhaps it's my ignorance, but I don't see us approaching, much less > getting better than 99.9% accuracy. And let's be honest, in any other > field, 99.9% accuracy is really good accuracy. > To clarify: my point was not "99% is not good enough". My point was - 99% effective ESP defenses in normal scenarios end up completely ineffective for replay scenarios, IF you measure based on volumes of spam sent. When a single message turns into 100 million replays, attackers can justify spending a lot of time and effort to get that 1 message out. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On 12/16/22 12:36 PM, Evan Burke wrote: As pointed out in another response, the amplification factor of replays means that signup anti-spam systems which are 99% effective are not good enough; even manual review is imperfect at scale. All it takes is a single malicious account to get through review, and you can have millions of replays happening. If possible, please add some numbers to the conversation. Does anyone have any idea how many millions of messages Google / Yahoo / Microsoft (individually or combined) send per say? To me, it turns into a numbers game. Even if we get less than 0.1% slipping through, that's still a LOT of messages slipping through. 1,000,000,000 messages with 99.9% accuracy is still 1,000,000 unwanted messages. Perhaps it's my ignorance, but I don't see us approaching, much less getting better than 99.9% accuracy. And let's be honest, in any other field, 99.9% accuracy is really good accuracy. I do see more and more email being sent. So if we can't realistically improve accuracy, and the number of messages sent a day continues to grow, the number of unwanted messages is going to continue to grow. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On 12/16/22 3:10 PM, Evan Burke wrote: I ask because I would assume that a proper DKIM signature including the To: header would mean that the message could only be replayed to the same recipient and pass DKIM validation. -- There is the separation between the envelope RCPT and the To: / CC: headers. The separation between RCPT TO and To: (or CC:) is exactly what's being exploited here. To: is present, the signature covers it and is valid, but To: does not match the RCPT TO address. Just like BCC delivery. But the message-id is common across all of the transactions, and it's normally signed (MUST ?). So you could certainly detect that it's essentially a big bcc. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
(Sorry, forgot to reply to the list on my previous message. Grant's quotes include it in full.) On Fri, Dec 16, 2022 at 1:57 PM Grant Taylor wrote: > On 12/16/22 12:50 PM, Evan Burke wrote: > > Yes, but the other issue is there's no reliable real-time reporting or > > monitoring mechanism to tell you your domain is getting replayed*. > > It doesn't seem like the lack of real-time reporting is isolated to > DKIM. The lack of real-time reporting seems like a larger issue that > far supersedes anything that DKIM can do. > > > So you wait for end recipients to send you spam complaints, sometimes > > a day or two later, or you use ISP provided tools which are available > > with 1 day delay, and that's quite a bit too long when an attacker > > can send on the order of 50-100 million per hour. > > I know that replay spam is an issue. But I don't understand the > mechanics of it. Do the messages not include a To: header? Or is it > something like "undisclosed recipients"? > > I ask because I would assume that a proper DKIM signature including the > To: header would mean that the message could only be replayed to the > same recipient and pass DKIM validation. -- There is the separation > between the envelope RCPT and the To: / CC: headers. > The separation between RCPT TO and To: (or CC:) is exactly what's being exploited here. To: is present, the signature covers it and is valid, but To: does not match the RCPT TO address. Just like BCC delivery. > > * With the exception of DKIM-based complaint feedback loops. As far as > > I'm aware, replay spam volume has been many orders of magnitude higher > > to domains which *don't* offer those. I suspect that's intentional. > > Probably. > > ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On Wed, Dec 14, 2022 at 3:54 PM Jim Fenton wrote: > > I’m not an ESP, of course, but it seems like they need to do more vetting > of new customers (like perhaps manually reviewing their mailings) until > they are convinced those new customers are good actors. I realize this is > an expensive thing to do, but the ESPs are, after all, loaning their good > email reputation to their customers and they need to protect that. Because > of relays, this needs to be done even if those customers appear to be > sending to a relatively small list of recipients. > As pointed out in another response, the amplification factor of replays means that signup anti-spam systems which are 99% effective are not good enough; even manual review is imperfect at scale. All it takes is a single malicious account to get through review, and you can have millions of replays happening. Responding more generally to some of the other questions about the structure of these messages/attacks, and why various proposed detection methods aren't useful: - SPF? They just change the MFROM, that can't be signed; no mechanism exists that enforces DKIM d= and MFROM domain alignment, and a significant amount of legitimate mail does not align between those two domains, so that's not a useful reputation identifier. - DMARC? Attacker controls the From domain, or uses a shared domain with no DMARC record or with a p=none record. - DNSBLs? Most DNSBLs don't have spamtrap representation at large consumer mailbox providers, so they're blind to this spam. - Limited ipv4 space? You can find a lot of non-sequential, clean enough IPs if you spend time and effort on it. (And they do.) - Large sets of RCPT TOs? Attackers replay messages individually instead, just like legitimate high volume email delivery systems. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
