Re: [Ietf-dkim] Misuse of antiforgery protocols
On Sun, 25 Dec 2022, you wrote: >> It's easy to sort wanted mail between forwards/mailing-lists and normal >> narrow-casted mail. Spam can masquerade as either; but if possible a >> spammer would want to look like narrow-casted mail as that is the only >> kind that could be expected to arrive from a stranger. To use this >> exploit, they must give that up. >> > If you're talking about replay, I don't understand "must". The replay > attack under discussion works fine if it's unicast. The spammer wants it to *look* unicast, not actually be unicast. That means the From: and To: align with MAIL FROM: and RCPT TO:, and that the single From: address passes all available forgery checks. The To: header is covered by DKIM, hence the spammer *has* to use a generic To: that can be correct for at most a single intended victim. While in theory he could do the trick once for each victim, that's silly as it means one pass through the singer-victim's smarthost *per* spam victim. He's giving up the advantage of blinding his signer-victim's Abuse Desk to the true "fan-out" of his e-mail, which is the only reason to consider this hack. Michael Deutschmann ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On Mon, 12 Dec 2022, you wrote: > > Blind-carbon-copy is already a sign of spam. > > Except when it's not, like this very mailing list. Only if you don't whitelist *all* forwarders you set up and mailing lists you have joined first, overriding the Bcc filter on a match. This does mean Bcc-blocking is an anti-spam trick that most ISPs are absolutely incapable of using because they do not know their users well. But it's not the first anti-spam technique to have this problem. DCC also requires mailing list whitelisting. So does a recieverside SPF implementation that actually has an effect on deliverabilty, is correct, and not Baka. (It's Baka to give any attention to a Pass without an explicit whitelist of the sender, it is incorrect to give any attention to a Fail when you don't have a complete forwarder whitelist.) It's easy to sort wanted mail between forwards/mailing-lists and normal narrow-casted mail. Spam can masquerade as either; but if possible a spammer would want to look like narrow-casted mail as that is the only kind that could be expected to arrive from a stranger. To use this exploit, they must give that up. The way I look at it, up to now there have been two main approaches to spamming, and this trick may add a third. 1. First, the old-school chickenboner tactics where you forge everything you can get away with, and often try to exploit systems you don't own to conceal your true ISP. 2. Second, the approach that tries to exploit Baka recieverside deployments by actually buying a domain and pretending to be a newly-minted vanity domain sending narrow-casted mail with perfect SPF/DKIM/alignment credentials. The mail still is broadcast, but in one transaction per victim so it's not obvious to an automated system. 3. Finally, the new trick. It also lets you exploit the Baka, but locks you in to pretending to be a mailing list. All along, it looks to me that #2 is still pareto superior to #3 for the bad guys. Although one thing that might explain the fuss; maybe the point of sealing this hole is that the big e-mail providers would like to agree to whitelist each other in a top-down fashion without user input, rather than bottom-up whitelisting of one email address at a time by user request. If a provider was silly enough to make such an arrangement, then they could be vulnerable to #3 alone, because vanity domains (both friendly and spammer) aren't part of the cartel. Michael Deutschmann ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On Sun, 11 Dec 2022, Murray S. Kucherawy wrote: > Then from that other account I can spray it to as many recipients as I > want so long as the only thing I change is the envelope. Since the ISP is doing the signing, you can't stop them from using a signature that protects the To: and Cc: from modification, and in practice everyone already does that. That means the bonus messages you get to send via the hack will have mismatched 822 and 821 recipients, equivalent to a blind-carbon-copy. Blind-carbon-copy is already a sign of spam. Long ago, it was because the bad guys were using open relays, and could spam faster by issuing many RCPT TO:s to the relay in one transaction. (I remember being puzzled back then that most of my spam came "To: fri...@public.com" rather than my address at the time.). In modern times, you still see it from "Nigerian" scammers who seem to be using real webmail sites and copy-pasting huge address lists into a literal Bcc: field. Michael Deutschmann ___ 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, 7 Dec 2022, Neil Anuskiewicz wrote: > I wish that certain widely used distribution list software could do the > same. So you admit that most mailing lists are not compatible with an enforcing DMARC, so my original point stands. It's a bit annoying that after almost two weeks, the only responses in this thread have been about this side issue, with my main point unaddressed. I'm going to try to fight the real problem with a coinage, "Baka-DKIM" (and its cousin "Baka-SPF"). (In case of any Pop Cultural Osmosis Failure here, "Baka" means fool in Japanese.) Baka-DKIM is the error of upscoring messages for being DKIM signed without caring about *what* the email address being attested actually was. (The avoided "downscore" when DMARC says to enforce signing doesn't count. Still, when the mail is from a stranger, that case must not be in total upscored relative to the no-DKIM and no-DMARC case, everything else equal.) If your configuration is not Baka, then you have nothing to fear from the replay attack. The replay attack only allows an attacker to pretend to *continue* to own an e-mail address they just lost; it never lets them impersonate someone who already has a good reputation. If you are Baka but apply a downscore for blind-carbon-copy of equal-or-greater magnitude than your Baka upscore, you are also immune to the replay attack. But you will still be wide open to other spammers. Michael Deutschmann ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] Misuse of antiforgery protocols
(I've noticed the "rechartering" thread, but I don't think it should squelch this since I am speaking meta to the replay exploit, not suggesting technical measures.) More than a hundred e-mails have streamed through my in-box lately, all about a silly exploit in DKIM. While it is real, I immediately notice that it can't really do any damage if the recipient is using DKIM *properly*. It's important to remember that DKIM/DMARC is an anti-forgery protocol, not an anti-spam protocol. There are *two* ways an anti-forgery technique can provide useful input to an anti-spam system: First, if the anti-forgery technique can assert that a message *is* forged, and not just failing the test because the alleged sender isn't participating, then it is reasonable to ignore any heuristics indicating the message is not spam, and fail it. Second, if the anti-forgery technique asserts the message is genuine, and *YOU* *KNOW* *THE* *RECIPIENT* *TRUSTS* *THAT* *SPECIFIC* *SENDER*, then it is reasonable to ignore any heuristics indicating the message is spam, and pass it. Going further is folly. Without trust in the identity claimed, all anti-forgery-system blessings just become Habeas Haikus (anyone remember that?). Last I looked, DMARC makes no allowance for the mailing list problem; either you know none of your users posts to any mailing list or your DMARC policy has to be inert. Practically, only an address from a public e-mail provider can be "forged" by the hack. And those providers cannot assume they have no users who use mailing lists, so (if sane) their DMARC will always be inert. Even if someone attemped the exploit but accidentally still broke the signature, the hard-failure case would never apply. The spammer has to at least momentarily control the address he uses as From: -- he cannot forge someone his victim trusts (Unless the e-mail provider is lazy and doesn't check for internal address forgery before signing, which would be their fault alone). So the hard-success case will also never apply on exploit mail. It's only fools who can't accept the truth that DKIM can only give anti-spam input for a miniscule proportion of incoming mail, and thus upscore all signed mail, who have to fear this hack. And if this hack was miraculously blocked, they'd still be wide open to more straightforward spammers. Ones who pay for their own domain and happily participate in every antiforgery scheme. Michael Deutschmann ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
