Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote: > 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. I suppose if the thresholds are high enough, it won't hit much in the way of legitimate mail (as an example, I anticipate this message will hit at least hundreds of mail boxes at Gmail, but not millions), but of course letting the first X through isn't ideal. If I had access to a database of numerically scored IP reputation values (I don't currently, but I have in the past, so I can imagine this at least), I think I'd be more inclined to look at the reputation of the domain as a whole (something like average score of messages from an SPF validated Mail From, DKIM validated d=, or DMARC pass domain) and the reputation of the IP for a message from that domain and then if there was sufficient statistical confidence that the reputation of the IP was "bad" compared to the domain's reputation I would infer it was likely being replayed and ignore the signature. I think that approaches the same effect as a "too many dupes" approach without the threshold problem. It does require reputation data, but I assume any entity of a non-trivial size either has access to their own or can buy it from someone else. Scott K ___ 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 2/14/23 1:16 PM, Evan Burke wrote: 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. The problem draft mentions it, but if it's Yahoo doing it have they documented it? Or is this just hallway chatter, maybe? One thing that occurs to me is that if filters can have knobs to dial up the sensitivity of detection (at risk of false positives), maybe that can be applied if you're seeing tons of dups. That would be especially frustrating to a spammer since they could get something through in the small only to be detected as spam when they are trying to exploit it. Mike ___ 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 2/14/23 11:30 AM, Murray S. Kucherawy 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? 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. And to be clear, what do you mean by "oversigning"? Is it something different than just signing the Subject, etc, header in the first place? This was a term invented to refer to the technique described in Section 8.15 of RFC 6376. Ok, thanks. Mike ___ 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: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? > 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. > And to be clear, what do you mean by "oversigning"? Is it something > different than just signing the Subject, etc, header in the first place? > This was a term invented to refer to the technique described in Section 8.15 of RFC 6376. -MSK ___ 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 2/13/23 9:43 PM, Evan Burke wrote: 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. I have to say that there is a fair amount of irony in my eyes going on here. Even though I'm fairly skeptical about what we can actually do about this, it's very ironic that x= was my idea (it was in the original IIM draft) and that there was a lot of skepticism back then about its utility which I had to push back on. Have you considered something like rate limiting on the receiver side for things with duplicate msg-id's? Aka, a tar pit, iirc? And to be clear, what do you mean by "oversigning"? Is it something different than just signing the Subject, etc, header in the first place? Mike ___ 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 14/Feb/2023 06:43:22 +0100 Evan Burke wrote: 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. [...] 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. Aha, (2) implies different signing based on account. Are there other differences in the signatures, in particular of the type that can be seen by receivers (e.g. i=bullshitters@...)? Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
