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 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ 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 16/02/2023 23:17, Dave Crocker wrote: On 2/16/2023 2:04 PM, Evan Burke wrote: 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. The historical common choice, for when to stop retrying mail delivery, has been 3 days. This was a matter of discussion some years ago and as I recall, was a comfortable choice. And we got a note observing that replay attack can reasonably begin within minutes of original posting. This produces a choice for setting a timeout that is wholly ineffective or one that destroys retries of leigimate mail delivery attempts. Does that not assume that the point where a message is held during delay is after the point of signing? -- Cheers, Jeremy ___ 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/16/2023 2:04 PM, Evan Burke wrote: 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. The historical common choice, for when to stop retrying mail delivery, has been 3 days. This was a matter of discussion some years ago and as I recall, was a comfortable choice. And we got a note observing that replay attack can reasonably begin within minutes of original posting. This produces a choice for setting a timeout that is wholly ineffective or one that destroys retries of leigimate mail delivery attempts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ 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
This could apply to other things like over some rate limit threshold or the reputation based approach I suggested as well. The key thing that's relevant to the problem statement is that the problem is how the reputation impact of the signature is applied, not signature continues to validate after replay. Scott K On February 16, 2023 10:13:03 PM UTC, Barry Leiba wrote: >I like this approach: if the issue is that an "expired" signature is >treated as unsigned, I think we have an unacceptable level of false >positives. But if the fact that a signature is valid but expired is >simply another factor in the decision, I think we might be OK, keeping >in mind that "x=" is purely advice to the validator. To *really* >expire a signature, one has to stop publishing the key associated with >the selector. > >Barry > >On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman >wrote: >> >> >> >> On February 16, 2023 9:21:51 PM UTC, Michael Thomas wrote: >> > >> >On 2/16/23 12:56 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. >> > >> >I dunno, I would think it has to do with how much of a boost reputation is >> >actually giving deliverability. For typical marketing email that's not too >> >spammy maybe it doesn't make much difference? Adding signatures and a SPF >> >record is pretty easy to do these days, so it's sort of a no-brainer to >> >just do it. But if some small percentage with slow delivery fall through >> >the cracks, how adverse is that to delivery, assuming they don't have a >> >p=reject policy? That seems like it should be a pretty measurable thing for >> >an ESP. >> > >> >Sounds like something that Evan might know. Actually it might well be worth >> >adding that kind of estimate to the problem statement to judge how much of >> >a problem it is. What we have now is very hand waving and makes it >> >impossible to judge about how heroic we need to be. >> >> I think this highlights a key consideration that's easy to forget. >> Ultimately the issue is not that a 'bad' message was delivered, but that a >> 'bad' message got the benefit of whatever positive reputation was provided >> by the signature. If one decides under X circumstances we will ignore a >> DKIM signature for Y purposes, then the negative impact of that is far less >> than that associated with rejecting the message, so we can probably tolerate >> more false positives. >> >> Scott K >> >> ___ >> 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] DKIM Replay Problem Statement and Scenarios -01 draft posted
I like this approach: if the issue is that an "expired" signature is treated as unsigned, I think we have an unacceptable level of false positives. But if the fact that a signature is valid but expired is simply another factor in the decision, I think we might be OK, keeping in mind that "x=" is purely advice to the validator. To *really* expire a signature, one has to stop publishing the key associated with the selector. Barry On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman wrote: > > > > On February 16, 2023 9:21:51 PM UTC, Michael Thomas wrote: > > > >On 2/16/23 12:56 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. > > > >I dunno, I would think it has to do with how much of a boost reputation is > >actually giving deliverability. For typical marketing email that's not too > >spammy maybe it doesn't make much difference? Adding signatures and a SPF > >record is pretty easy to do these days, so it's sort of a no-brainer to just > >do it. But if some small percentage with slow delivery fall through the > >cracks, how adverse is that to delivery, assuming they don't have a p=reject > >policy? That seems like it should be a pretty measurable thing for an ESP. > > > >Sounds like something that Evan might know. Actually it might well be worth > >adding that kind of estimate to the problem statement to judge how much of a > >problem it is. What we have now is very hand waving and makes it impossible > >to judge about how heroic we need to be. > > I think this highlights a key consideration that's easy to forget. > Ultimately the issue is not that a 'bad' message was delivered, but that a > 'bad' message got the benefit of whatever positive reputation was provided by > the signature. If one decides under X circumstances we will ignore a DKIM > signature for Y purposes, then the negative impact of that is far less than > that associated with rejecting the message, so we can probably tolerate more > false positives. > > Scott K > > ___ > 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] 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 February 16, 2023 9:21:51 PM UTC, Michael Thomas wrote: > >On 2/16/23 12:56 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. > >I dunno, I would think it has to do with how much of a boost reputation is >actually giving deliverability. For typical marketing email that's not too >spammy maybe it doesn't make much difference? Adding signatures and a SPF >record is pretty easy to do these days, so it's sort of a no-brainer to just >do it. But if some small percentage with slow delivery fall through the >cracks, how adverse is that to delivery, assuming they don't have a p=reject >policy? That seems like it should be a pretty measurable thing for an ESP. > >Sounds like something that Evan might know. Actually it might well be worth >adding that kind of estimate to the problem statement to judge how much of a >problem it is. What we have now is very hand waving and makes it impossible to >judge about how heroic we need to be. I think this highlights a key consideration that's easy to forget. Ultimately the issue is not that a 'bad' message was delivered, but that a 'bad' message got the benefit of whatever positive reputation was provided by the signature. If one decides under X circumstances we will ignore a DKIM signature for Y purposes, then the negative impact of that is far less than that associated with rejecting the message, so we can probably tolerate more false positives. 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/16/23 12:56 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. I dunno, I would think it has to do with how much of a boost reputation is actually giving deliverability. For typical marketing email that's not too spammy maybe it doesn't make much difference? Adding signatures and a SPF record is pretty easy to do these days, so it's sort of a no-brainer to just do it. But if some small percentage with slow delivery fall through the cracks, how adverse is that to delivery, assuming they don't have a p=reject policy? That seems like it should be a pretty measurable thing for an ESP. Sounds like something that Evan might know. Actually it might well be worth adding that kind of estimate to the problem statement to judge how much of a problem it is. What we have now is very hand waving and makes it impossible to judge about how heroic we need to be. 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
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. ... 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, Glad to see the challenge of using x= characterized here. I suggest two points that probably need considering: 1., Realistic, real-world examples where the proposed mechanism is known to work and to work well. The idea that it is possible to have signature expiration be short enough to be useful against replay, without destroying DKIM's primary use, does not seem even slightly realistic to me. So field demonstration of utility seems essential. 2. Moving heuristic advice to a discussion paper, rather than a technical specification. There's nothing wrong with documenting things that someone, somewhere might find useful, but with caveat emptor warnings highlighted. But no, those are not technical specifications. -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ 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
>> 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. Barry ___ 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 February 16, 2023 8:03:01 PM UTC, Evan Burke wrote: >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. I'm not necessarily opposed to going down this kind of path, but it should be with eyes open on the side effects. I'm all about practical, but in my book that includes not creating an attractive nuisance that causes more problems than it solves (not saying that X= is that, I don't have much of an opinion yet). 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 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 February 16, 2023 6:10:39 PM UTC, Evan Burke wrote: >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. Okay. What's the value for X - T that prevents this problem, but doesn't cause DKIM signatures of "normal" mail to fail? 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 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 2/16/2023 2:39 AM, Laura Atkins wrote: The flip side of that is that spammers are not equal opportunity: they target the large consumer mailbox providers. So if the problem only affects groups that are this tall, then a solution that fixes it for those providers might be reasonable. This nicely imposes an initial requirement to formulate the concrete details of the height requirement, in a fashion that permits reasonably objective, reliable application for determining whether they are appropriate for the ride. Who is the spec intended for, exactly, and how can they tell, reliably an accurately, that they are in the target market? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ 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 10:49 PM Evan Burke wrote: > >> 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. > 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? -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 16 Feb 2023, at 04:16, Murray S. Kucherawy wrote: >> >> There are *tons* of external dependencies on the filtering MTA. I really >> can't imagine that this would be the straw that breaks the camel's >> back. > > Depends (as I think Scott said) on the size and resources available to the > operator, and how much they're a target of this attack. We've generally > shied away in the past from solutions of the form "you have to be at least > this tall to play". The flip side of that is that spammers are not equal opportunity: they target the large consumer mailbox providers. So if the problem only affects groups that are this tall, then a solution that fixes it for those providers might be reasonable. 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
