Re: [Ietf-dkim] Misuse of antiforgery protocols
On Wed, Dec 14, 2022 at 4:47 PM Grant Taylor wrote: > > That way if ~> when the ESP needed to cancel a client's service, the ESP > could also withdraw the client's public key in the ESP's zone(s) thereby > breaking the DKIM signature by rendering it unvalidatable. I'd think > that this would largely comedown to a TTL issue on the DKIM's public key > record in DNS and implementation complexity. > > What am I failing to take into account? > Generally: x= is automatic and will usually be faster, and requires no engineering effort to build out the key management service, and no ongoing operational/maintenance/infrastructure costs. Looks like a lot of complexity for little to no benefit over x=. ___ 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/14/22 11:10 AM, Evan Burke wrote: It doesn't. Most of the accounts are caught before sending. All it takes is one to slip through the anti-spam detections and then go send millions of replay spam messages or more - even if that account is shut down quickly after sending. What would happen if the ESPs DKIM implementation got, possibly a LOT, more complex in that key pairs used to sign outgoing email from clients with keys specific to each client? That way if ~> when the ESP needed to cancel a client's service, the ESP could also withdraw the client's public key in the ESP's zone(s) thereby breaking the DKIM signature by rendering it unvalidatable. I'd think that this would largely comedown to a TTL issue on the DKIM's public key record in DNS and implementation complexity. What am I failing to take into account? -- 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 13 Dec 2022, at 9:06, Evan Burke wrote: > On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton wrote: > >> 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. 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. I am less sympathetic to this problem if it is primarily the result of insufficient diligence on the part of ESPs. -Jim ___ 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/14/22 3:46 PM, Jim Fenton wrote: On 13 Dec 2022, at 17:00, Michael Thomas wrote: 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? Some people use receive-side forwarders (e.g., college alumni addresses) to have a consistent email address if they change ISP. That will, completely legitimately, cause SPF failures on transactional email. There are tons of other options these days. But I really wasn't talking about that part. It's what happens before it gets forwarded. If it arrives in a giant bcc where SPF fail and the domain normally passes, that seems like a red flag. 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 13 Dec 2022, at 17:00, Michael Thomas wrote: > 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? Some people use receive-side forwarders (e.g., college alumni addresses) to have a consistent email address if they change ISP. That will, completely legitimately, cause SPF failures on transactional email. -Jim ___ 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/14/22 3:06 PM, Murray S. Kucherawy wrote: On Tue, Dec 13, 2022 at 5:00 PM Michael Thomas wrote: 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? Right. IP address gets a bad reputation? Move to another one. Domain blocklisted? Register another one. etc. Any bad reputation is trivially exchanged for a neutral one. That leaves us in a world where only positive reputations are meaningful, and presumably once you have one you'll work to protect it. Unless they're running ipv6, that's getting harder and harder to do, of course. And don't DNSBL's also blacklist subnets too? That's certainly not optimal for whoever is hosting them. ipv4 space costs money these days. 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. Yep, but if a receiver values DKIM more than SPF, for instance, then maybe they're willing to forgive that lack of support. Maybe the forwarding problem bugs you enough that you're forced into such a position, for instance. 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? Yes, but that doesn't work for all applications or flows. It depends on what tolerances work for your use case and your users. It seems to me that the attack is a pretty narrow use case. That is, spam disguised as marketing email. That seems like a use case that SPF covers well. And it would be really suspicious to have a mile long set of RCPT-TO's for that kind of use case where SPF fails, right? And I'm not sure why they would prefer one or the other -- they are just inputs to a larger data set. But if something with good reputation that normally passes SPF too starts sending mail where SPF fails, that's like a red flag, right? Again the ESP use case should be pretty predictable. 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 Tue, Dec 13, 2022 at 5:00 PM Michael Thomas wrote: > 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? > Right. IP address gets a bad reputation? Move to another one. Domain blocklisted? Register another one. etc. Any bad reputation is trivially exchanged for a neutral one. That leaves us in a world where only positive reputations are meaningful, and presumably once you have one you'll work to protect it. > 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. > Yep, but if a receiver values DKIM more than SPF, for instance, then maybe they're willing to forgive that lack of support. Maybe the forwarding problem bugs you enough that you're forced into such a position, for instance. > 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? > Yes, but that doesn't work for all applications or flows. It depends on what tolerances work for your use case and your users. > 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. > Sure but on my email, I would like you to have only positive signal, to the extent I can control that. Or, at least, as little negative signal as possible. -MSK ___ 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 2:10 AM Alessandro Vesely wrote: > Would someone please explain this trick to me, who never contacted an ESP? > > From what I heard, I imagine someone opens new account at Mailchimp, say, > creates a campaign and sends a test message to herself, which she will > later > replay. How come it works every time? > It doesn't. Most of the accounts are caught before sending. All it takes is one to slip through the anti-spam detections and then go send millions of replay spam messages or more - even if that account is shut down quickly after sending. This means there are incentives for attackers to put a lot of time and effort into getting that one account successfully created, even if that means a lot of failed attempts in the process. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Misuse of antiforgery protocols
On Tue 13/Dec/2022 18:06:55 +0100 Evan Burke wrote: On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton wrote: 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. Would someone please explain this trick to me, who never contacted an ESP? From what I heard, I imagine someone opens new account at Mailchimp, say, creates a campaign and sends a test message to herself, which she will later replay. How come it works every time? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
