Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?
On Fri, Jan 19, 2024 at 7:01 AM Dave Crocker wrote: > On 1/19/2024 6:51 AM, Al Iverson wrote: > > I'm > sort of boggling at the attempt to keep potential header changes and > DKIM oversigning out of the exploit definition and potential solution > consideration. I just don't think it makes sense to exclude this. > > > It makes sense because oversigning is sufficient to cover the cases of > re-posting that 'merely' add header fields, whereas the scenario of sending > to a collaborating receiver and re-posting a message that has no > differences except the envelope rcpt-to value, does not have a know > solution. > > Insisting on using the same term for these two different cases has an > academic purity to it, but has already been demonstrated to be destructive > in practical terms, because it creates confused discussion. > No, that's exactly backwards. The oversigning case is a subset of the general DKIM replay case, because mitigation techniques for general DKIM replay - they do exist, though they are imperfect - also apply to cases where header addition has taken place. Oversigning is a defense against the subset of DKIM replay where headers have been added, but not the general case. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?
On Tue, Jan 16, 2024 at 8:58 AM Dave Crocker wrote: > Ahh. OK. Oversigning, to prevent sending a version of the message onward > -- but with one or another field added -- is generally viewed as a Good > Thing. I have tried to locate one, but I believe there are some best > practices documents that give advice about doing it. > > However it is not what is meant by DKIM Replay. > > DKIM Replay re-sends an /unmodified/ copy of the message, where only the > SMTP RCPT-To is different. DKIM doesn't (and can't) cover that SMTP > command. > I'd call it DKIM replay if the signature is intact. For a little while, attackers used duplicate Subject and/or Date headers (subject to replace an innocuous subject line used on our platform to avoid getting caught by filters, replaced with their spam payload subject line, and Date presumably to avoid negative reputation effects from old Date headers in replays). Without oversigning those headers, DKIM would pass, since the original headers were still present and unmodified, in addition to the new headers added by the attacker. As noted by others, these duplicate headers violate RFCs, and I saw several mailbox providers add tighter checking of mail against RFCs as a defense against this type of DKIM replay. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] What makes this posting different from the original posting?
On Thu, Sep 7, 2023 at 10:17 AM Murray S. Kucherawy wrote: > On Thu, Sep 7, 2023 at 10:03 AM Dave Crocker wrote: > >> Keys cannot be rotated fast enough to be useful within the time frame >> that attackers work in. >> >> Key rotation works in a timeframe of days or weeks. Attackers work in >> the timeframe of minutes. >> > > I think we disqualified use of "x=" as a mitigation on the same basis. > To be clear, for us x= was one of the most effective defenses against large-scale replay attacks. Not perfect, obviously, but applied carefully and in conjunction with header oversigning, it created a significantly narrower window for attacks, and reduced the potential financial return to attackers from replay spam. I would note that the effectiveness of x= for reducing replay risk will likely vary considerably from signer to signer, depending on a number of factors; we may be better positioned than many signers in that respect. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay is a bogus concept
On Tue, Aug 15, 2023 at 9:29 AM Emanuel Schorsch wrote: > Still, knowing that he's a bad actor, you could skip signing. Are there >> so >> many new spammers every day? Or, rather, there is a bunch of >> professional >> spammers who know how to hide? >> > > Just to answer the second question: Yes, absolutely. Spammers are fully > professional and organized groups. Some of those groups are extremely > sophisticated. They control a huge number of resources: IPs, domains, > accounts. There are black market account resellers who provide spammers > with large numbers of accounts at different organizations. Those accounts > are sourced in a variety of sophisticated ways: manual creation in low cost > countries, bulk hijacking (through data dumps, common passwords etc.). > > I won't pretend that there aren't some aspects of spam that can be solved > by caring more and making simple changes. But I do want to emphasize that a > number of very large spammer groups are extremely sophisticated and > persistent. > This is our experience as well. Some signs pointed to a single sophisticated spam group executing the majority of DKIM replay attacks. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption
+1 On Thu, Apr 6, 2023 at 9:19 AM Mickey Chandler wrote: > +1 from me as well. > > On Tue, Apr 4, 2023 at 10:50 AM Laura Atkins > wrote: > > > > I want to thank everyone for their patience as I learn IETF processes > and tools. Tim and I are working on a statement for the group from us as > chairs. While we’re doing that, though, I would like to get the group > moving forward and get some text adopted. > > > > I have issued a Call for Adoption for Wei’s draft so that we have text > to work with and on. The list is still on moderation status but we will be > approving posts. > > > > laura > > > > > > > > > > > > > > -- > > The Delivery Experts > > > > Laura Atkins > > Word to the Wise > > la...@wordtothewise.com > > > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > > > > > > > > ___ > > Ietf-dkim mailing list > > Ietf-dkim@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-dkim > > ___ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim > ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Clarifying the problem
Murray's answers are largely correct. I'll fill in some additional detail below. On Fri, Feb 17, 2023 at 11:10 AM Michael Thomas wrote: > 3. Do senders filter outbound traffic for spam? > 4. Do spammers who get a piece of email signed by a sender also send mail to target domains to see if it passes their filters? Yes and yes. The testing behavior in #4 is also used on outbound filters. > 12. Do spammers provide an unsubscribe link which is typical on normal email blasts? If not, is that unusual and/or against the rules of the bulk provider? If so can the sender keep track of that? > 13. Can senders verify that opt-out links actually work especially for new accounts? You're giving DKIM replay spam much more credit than it deserves. It's bottom of the barrel stuff - scams, fraud. It has no use for an unsubscribe link. Also, nearly all email marketing platforms provide an integrated unsubscribe link as part of the platform functionality; some go so far as to prohibit 3rd party unsubscribe links entirely. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Fri, Feb 17, 2023 at 9:49 AM Michael Thomas wrote: > > Which brings up another question which is applicable to the problem > statement: are mailbox providers like gmail, hotmail, etc getting abused > from these replays? Some spam from whokn...@hotmail.com doesn't seem > like a very good address from arriving spam. For that matter, do bulk > senders even allow their domain to be the From domain? It seems like a > pretty easy way to not affect their reputation is to require that the > mail be sent in the name of somebody else's domain. > There's a good amount of bulk mail sent with d= that doesn't match the visible From domain. Those signatures are typically used for DKIM based complaint feedback loops, and because they grant reputation to "mom&pop" non-technical customers who either don't own a domain or haven't set up DKIM yet. That DKIM d= domain has reputation on its own, independent from the visible From domain reputation. While I'm sure some replay spam is sent where there is a match between these two domains, it's entirely possible that attackers tend to prefer unaligned signatures, because that prevents the replay spam from showing on DMARC reporting for the d= domain being replayed. Taking Alessandro's idea a bit further with that fact in mind - what if we had DMARC-style reporting specific to the d= domain? That could give us useful data about where/when signatures are being used, and if/when they are breaking. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Thu, Feb 16, 2023 at 3:32 PM Dave Crocker wrote: > On 2/16/2023 3:23 PM, Jeremy Harris wrote: > > Does that not assume that the point where a message is held during > > delay is after the point of signing? > > Yes, because it often and maybe nearly always is. Even a single site > can have multiple 'points' where processing of a message happens. > Prepping and packaging a message would likely be done a long way before > retry queuing happens. > Signing on each attempt is fairly common, at least among my peers. I think this might just be because certain popular commercial MTA products do it that way by default, and in practice it doesn't usually add enough load for users to need to change the signing behavior. In any case, it is an important distinction to make, and changes the equation quite a bit for appropriate values of x=. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Thu, Feb 16, 2023 at 12:57 PM Barry Leiba wrote: > >> Okay. What's the value for X - T that prevents this problem, but > doesn't cause DKIM signatures of "normal" mail to fail? > > > > There's not one "right" value; we're talking about distributions > > of timings for normal mail vs. replay, and yes, there's some > > overlap there. In practice I've seen many signers choose > > expirations in the range of 1hr to a few days. 1hr can be very > > good at limiting the opportunity for high volume replay, but I > > estimate "normal" signature breakage at that level is on the > > order of 0.1%. 24hr is probably effectively zero breakage, but > > with greater opportunity for replay. > > I think you're way off on these numbers, especially for the 1-hour > case. While normal circumstances get mail delivery in less than an > hour, I have seen *many* cases of legitimate mail delayed by hours -- > sometimes quite a few hours. I would consider anything less than two > days to be unacceptable, and with that sort of gap you don't do much > to prevent a spam blast. > Ok, this is an estimate based on a subset of our delivery data, and you have a point that some senders/signers are going to deliver much slower than we do. I'm certainly not globally authoritative on that. 1hr is at the very low end of the scale, only appropriate in narrow, specific circumstances. I think you're right that 2+ days is the right range for most mail. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Thu, Feb 16, 2023 at 10:45 AM Scott Kitterman wrote: > > On February 16, 2023 6:10:39 PM UTC, Evan Burke 40mailchimp@dmarc.ietf.org> wrote: > >The biggest current problem with replay is that it happens in bulk, at > >substantial scale. x= is effective against that because it takes time to > >send millions of messages. Is it perfect? No. But it's not difficult to > >choose between 10,000 replays using my domain vs. millions. > > Okay. What's the value for X - T that prevents this problem, but doesn't > cause DKIM signatures of "normal" mail to fail? > > There's not one "right" value; we're talking about distributions of timings for normal mail vs. replay, and yes, there's some overlap there. In practice I've seen many signers choose expirations in the range of 1hr to a few days. 1hr can be very good at limiting the opportunity for high volume replay, but I estimate "normal" signature breakage at that level is on the order of 0.1%. 24hr is probably effectively zero breakage, but with greater opportunity for replay. I understand the pushback; this is a list to talk about a standard, and standards tend to be a lot more binary in their functionality, so to speak. Maybe you're not receptive to a more practical solution - that's fine, I respect that - but I think there may be others here who are more open to that kind of approach. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Thu, Feb 16, 2023 at 7:30 AM Murray S. Kucherawy wrote: > > If my prior formulation is right, i.e., that the attack only takes a few > seconds to complete, what "x=" value are we proposing that will work here > without also bringing undesirable side effects? > > The biggest current problem with replay is that it happens in bulk, at substantial scale. x= is effective against that because it takes time to send millions of messages. Is it perfect? No. But it's not difficult to choose between 10,000 replays using my domain vs. millions. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Wed, Feb 15, 2023 at 8:16 PM Murray S. Kucherawy wrote: > On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas wrote: > >> >> There's also the question of whether "x=" is properly enforced. RFC 6376 >> says verifiers "MAY" choose to enforce it. I think I asked about this at a >> conference recently and was told that it's not universally supported by >> implementations. >> >> Others have said that the enforcement is pretty good. But I have no way >> to evaluate if that's true. >> > > I don't think we're saying different things. I remember the point of the > answer I got in that session being that most, but not all, implementations > check or enforce signature expiration. But that means if "x=" is the > solution we land on, we have to accept that a possibly-significant part of > the ecosystem won't be able to use that solution. > > Then again, anything new we roll out is going to take a while to become > universal anyway. > The short version is that x= works where it matters at the moment. As far as I've seen and heard from others, DKIM replay spam currently focuses heavily on replaying to recipients at just a few of the top 10 global mailbox providers. This is for reasons of economies of scale - roughly speaking, it might be viable to spend 1000 hours finding a way through the filters of a provider operating 200 million mailboxes, where it is not for a provider hosting 20 million. This is part of why I don't think we'll see replay attacks expand significantly to more domains; replay is just one ingredient in a larger spam recipe that takes a lot of other fine-tuning to achieve its intended effect. This has implications for rollout as well. I think the ideal solution would enable affected signers/verifiers to deal with the problem, while everyone else can ignore it entirely (until/unless they do see a problem). I think a count-based approach could do exactly that. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: > On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: > >> Have you considered something like rate limiting on the receiver side for >> things with duplicate msg-id's? Aka, a tar pit, iirc? >> > I believe Yahoo does currently use some sort of count-based approach to detect replay, though I'm not clear on the details. > > As I recall that technique is sometimes not suggested because (a) we can't > come up with good advice about how long you need to cache message IDs to > watch for duplicates, and (b) the longer that cache needs to live, the > larger of a resource burden the technique imposes, and small operators > might not be able to do it well. > > At maximum, isn't it just the x= value? It seems to me that if you don't > specify an x= value, or it's essentially infinite, they are saying they > don't care about "replays". Which is fine in most cases and you can just > ignore it. Something that really throttles down x= should be a tractable > problem, right? > > But even at scale it seems like a pretty small database in comparison to > the overall volume. It's would be easy for a receiver to just prune it > after a day or so, say. > I think count-based approaches can be made even simpler than that, in fact. I'm halfway inclined to submit a draft using that approach, as time permits. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas wrote: > On 2/10/23 2:10 PM, Evan Burke wrote: > > The M3AAWG BCP will cover recommended header signing/oversigning policies. > I'll make sure that's shared here when it's published. > > Any idea when that might drop? > I'll roughly summarize the guidance here for now. The primary audience for these recommendations is senders/signers with high volume shared signing domains; these domains are prime targets for replay because of their good reputation. Other approaches exist, but these are the ones that can generally be implemented relatively quickly. - Screen new accounts based on industry standard methods - Scan outbound mail for spam-like content, and restrict or block sending based on results. Pay closer attention to new accounts, or accounts that are otherwise high-risk. - Monitor for signs of replay via abuse reports and third party tools - Oversign Date and Subject headers - Set signature expiration via x=, with expiration on the order of 30 minutes to a few days, depending on details of your signing processes - After implementing oversigning and signature expiration, rotate keys - Consider signing mail from new or higher risk accounts differently - perhaps using a shorter signature expiration or different signing domain Implied here is that Date and Subject are signed in the first place, which in practice is almost always the case. In a small (n=35) survey of my own personal mail last year, 97% of sending platforms signed Subject, and 89% signed Date. Top two most effective techniques here, in terms of minimizing long-term viability of replay, are 1) signature expiration, and 2) shorter expiration for higher-risk accounts. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Mon, Feb 13, 2023 at 10:42 AM Michael Thomas wrote: > > On 2/13/23 2:49 AM, Laura Atkins wrote: > > > > Basically saying if you're not filtering outbound mail for abuse, > > you're part of the problem. > > > > I don’t see how that’s relevant to the discussion here. > It's extremely relevant. If you don't want to be viewed as a spamming > domain, do your part to not send spam. This really isn't rocket science. > > > > Most of the outbound mail is not detectable as spam (it’s not sent in > > bulk and it is sent to opt-in email addresses). So it won’t catch the > > send-one-message-to-myself case. If we’re looking at linking to spam > > landing sites, it’s trivial for the site to show one thing during the > > initial send and then be a wholly different site when it’s sent by the > > spammer. > According to some others here, the spammers have to go to elaborate ends > to not have it detected as spam. I don't recall if they specified > whether it was incoming or outgoing (or both) that they needed to evade. > Both - the spam group executing these replay attacks engages in extensive testing to identify and exploit any weakness in inbound and outbound filters. DKIM replay using a good-reputation signing domain is one way through certain inbound filters. Manual testing of different content, to find what's least suspicious, is a way through both outbound and inbound filters. (DKIM replay is not their only way through inbound filters, but it's what we're here to talk about.) No reasonable large-scale sender operates without outbound filtering, but given how much time this spam group spends finding content that passes filtering, and the high amplification factor of replay (1 million to 1 is not unheard of), outbound filtering is a minimally effective defense against replay. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas wrote: > | taking advantage of the flexibility in DKIM to >> | selectively sign headers, the spammer may intentionally leave out >> | certain headers such as To:, and Subject: that can be added in later >> | without damaging the existing DKIM signature. >> >> >> I think this needs to be explained. It isn't obvious to me how they would >> manage to do that. The header fields signed are under control of the >> signer, not the original author. How do the attackers coax the provider's >> signer into not signing certain fields? >> > By leaving them out. Many DKIM signers, having observed this > vulnerability, have started oversigning headers to prevent that. > > I think the draft should flesh this out a bit more. I mean, are they just > doing a bcc without a To: address? Are there other mechanisms? Is that > suspicious or is it a legit behavior? I don't think I've seen a message > without a To: address (or at least a legit one). > I more frequently saw replay attackers adding a second set of certain headers to the message during replay. As long as the original header was still present and matched the signature hash, the signature was intact. Regardless, oversigning solves both cases. (again, this will be important to inform possible BCP things, and in the > case of To: and Subject: to possibly making them required to be signed in a > protocol change. certainly that might be an interesting discussion) > The M3AAWG BCP will cover recommended header signing/oversigning policies. I'll make sure that's shared here when it's published. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote: > On 2/10/2023 11:35 AM, Wei Chuang wrote: > > ARC is a tool to help support modern Indirect Mail Flows, and I > > believe belongs in the solution space to be explored. > > Since ARC uses the same technology as DKIM and uses it in pretty much > the same was, my understanding is that it, too, has the potential for > replay. Having a reference to this fact makes sense to me. > > It doesn't need more than a mention, at this point, I believe, which > makes the current quick, reference exactly the right text, IMO. > +1 I realize there are some mixed opinions on ARC, but it's actively used on several of the world's largest email systems - some of the same ones where DKIM replay attacks are focused - so it's worth consideration as part of the solution space. It may not end up being a viable option, but now isn't the time to write it off. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat, Feb 4, 2023 at 11:07 AM Michael Thomas wrote: > On 2/4/23 11:02 AM, Evan Burke wrote: > > On Sat, Feb 4, 2023 at 10:15 AM Michael Thomas wrote: > >> Marketing email probably does. Whether it's spam or not is often in the >> eye of the beholder. >> > > Having spent some time in the industry, I can tell you that a significant > majority of marketing email service providers will deliver a unique > message, with a unique signature, for each individual recipient. DKIM > replay, in its most problematic current form, repeats one signature, often > millions of times or more. Even a very approximate count of h= or bh= > hashes can be a useful signal to distinguish direct vs. replayed > signatures. > > As I'm sure there are occasional cases where non-replay mail may re-use > the same signature a substantial number of times, I suspect any potential > mechanism based on this would need to be optional on both the signer and > validator side, requiring no changes to existing infrastructure unless a > signer or validator is interested in addressing this type of DKIM replay. > Seems like that could satisfy the people seeking a solution, and those > interested in avoiding any breaking changes. > > > I get tons of mail that's just the same blast to everybody. The larger > point is that we can't preclude that use case especially from a standards > standpoint. > I agree with that larger point, and I noted that in my second sentence above. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat, Feb 4, 2023 at 10:15 AM Michael Thomas wrote: > Marketing email probably does. Whether it's spam or not is often in the > eye of the beholder. > Having spent some time in the industry, I can tell you that a significant majority of marketing email service providers will deliver a unique message, with a unique signature, for each individual recipient. DKIM replay, in its most problematic current form, repeats one signature, often millions of times or more. Even a very approximate count of h= or bh= hashes can be a useful signal to distinguish direct vs. replayed signatures. As I'm sure there are occasional cases where non-replay mail may re-use the same signature a substantial number of times, I suspect any potential mechanism based on this would need to be optional on both the signer and validator side, requiring no changes to existing infrastructure unless a signer or validator is interested in addressing this type of DKIM replay. Seems like that could satisfy the people seeking a solution, and those interested in avoiding any breaking changes. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On Sat, Feb 4, 2023 at 8:47 AM Dave Crocker wrote: > On 2/4/2023 8:41 AM, Scott Kitterman wrote: > > I've yet to see a description of the problem that's distinguishable from > a mailing list that preserves DKIM signatures. > > That seems like an especially healthy discussion to have. Focusing on, > and seeking convergence about, the nature of the differences, could help > consideration of the ways to counteract replay. > In a word? Scale. Are there any mailing lists in existence that send tens of millions of messages a day, or more, in a way that preserves the original DKIM sig? ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Rechartering
On Sat, Dec 31, 2022 at 10:44 PM Wei Chuang wrote: > I'm worried about duplicating work unnecessarily as the M3AAWG has an email authentication BCP. If the WG to-be indeed does want to generate the BCP, perhaps the M3AAWG document can be the basis for an IETF document assuming M3AAWG is okay with that, or the WG can partner with M3AAWG to produce a common document. I think both are possible as there's a fair amount of people overlapping between the IETF and M3AAWG, and I know that M3AAWG organizationally wants to help here. I believe there's a revision underway for the general M3AAWG auth BCP doc, which will include a handful of sender-focused recommendations for reducing the viability of replay attacks. There is also a DKIM replay specific M3 BCP doc in progress with more in-depth recommendations. ___ 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
(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
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 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, 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] Taking Responsibility
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=. ___ 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, Dec 12, 2022 at 11:21 AM Michael Thomas wrote: > On 12/12/22 6:57 AM, Murray S. Kucherawy wrote: > > On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas wrote: > >> But I want to return to my previous point of whether reputation is even >> quantifiable, and whether somebody has actually gone out and researched it. >> We can say that this is a problem in theory, but do we have any data to >> back it up? I kinda think that should be table stakes before talking about >> rechartering. >> > > The industry appears to think it's a factor. This work comes to us from > M3AAWG where there's a critical mass that believes reputation abuse of this > nature is real. Though I agree it would be helpful to have metrics to > describe it more precisely, it's my perception that there's enough momentum > here to back chartering. > > So I take it they haven't quantified it either? This strikes me as highly > susceptible to using anecdotal evidence as proof. I'm not saying they are > wrong, I just would like to see actual evidence. That's especially true if > the end result is telling receivers they should do something that they have > no stake in. > I suspect that most of the organizations affected aren't positioned to share the internal metrics that showed impact, but I can tell you from experience the effects can be quite dramatic, and I've spoken to more than a few people - also with direct experience - who would say the same. 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. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On Mon, Nov 28, 2022 at 9:16 AM Dave Crocker wrote: > I thought spammers varied in skills and dedication and that simple > mechanisms that blocked lazy spammers was generally viewed as being > useful. Apparently that has changed, and now all spammers are highly > skilled, dedicated and well-funded? > Nobody's opposed to simple mechanisms if they effectively address the problem. The issue is - while it's fairly trivial to replay a single signed message, it gets quite a bit more complicated to do it successfully at scale. So for our purposes, we've already eliminated the lazy spammers; what we need are techniques that are effective against sophisticated ones. This doesn't fit the bill. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On Mon, Nov 21, 2022 at 5:03 PM Jim Fenton wrote: > I disagree with Jon (and Dave) on this. Spammers are notably agile — if > some mechanism they have been using stops working, they quickly adapt and > develop a workaround. In this case, they only need to arrange to have the > signed message relayed to an MTA they control, and their problem is solved. > In many cases they probably collect the signed messages from their own MTAs > already. > This is 100% correct; attackers are already using their own MTAs. Dropping signatures won't make a difference except at the margin. On the other hand, it makes it more difficult for legitimate senders to use DKIM - troubleshooting gets harder, teaching people about DKIM gets harder, etc. Regarding earlier discussion around weaknesses in x=; for many affected senders, a well-chosen x= may be the single most effective current defense against large-scale replay attacks. If the choice is between 5,000 replays and 5 million, that's an easy decision to make. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group
On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote: > > > The exception is a standardised mechanism to allow a sender/signer to > > indicate the [approximate] number of intended recipients, with which > > receivers might make fact-based decisions about when to recognise an > > instance of this particular attack > > For a mailing list, this is totally out of reach, unless the MLM itself is > the > (ARC) signer. Even then, when the MLM knows there are 1000 subscribers, > should > it extract the average per domain weight? I mean if 500 are @gmail.com > and > just 1 is @tana.it, should it extract the right figures for each receiver > or > send a rough total, which smaller mailbox providers cannot use? > > I disagree, this is perfectly fine. Approximate counts - even with an order of magnitude margin in some cases - would be an effective deterrent against large-scale replay attacks like what we've seen in the past year, where there could be 10s of millions of replays of a single message signature. Moreover, approaches based on signature hash count or similar would be likely to use approximate count algorithms at scale. I could imagine a draft including both a count-based solution, where a deterrent is good enough, or a more granular message-level solution, where tighter controls are needed, giving signers the option to use either or both based on their needs. ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] x= and DKIM replay
Hi, I'm reading the section in rfc6376 on the x= tag, specifically - INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay defense. Could anyone shed some light on the reasoning for this, by chance? I note that the spec for x= says "Signatures MAY be considered invalid [if past expiration]", which isn't particularly strong guidance for how verifiers should behave, but from my perspective, signature expiration could in theory be an effective tool (among other defenses) to help reduce the viability of replays. Thanks, -Evan ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
