Re: [Ietf-dkim] What makes this posting different from the original posting?
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote: > On 8/29/2023 7:46 PM, Grant Taylor wrote: > > On 8/29/23 9:02 PM, Dave Crocker wrote: > > > > Why not re-use the existing DKIM solution, just with a different > > domain / set of keys? > > Because it does not provide the affirmative information that I am > postulating/guessing the originating platform can supply. > I have to agree. It's compelling to consider that a high-trust domain might flag something for my extra consideration. This could be done per-message, rather than per-key, which was Grant's counterproposal; the equivalent is to generate a selector per message, which appears at least on the surface to suffer problems of scale. Rather than doing it in a header field, though, could it be done simply with a new tag? > Let a domain establish a bad reputation. Especially if it's being > > used for sending messages that are considered to be questionable. > > Establishing a reputation takes time. The likely behavior of a bad > actor is within a very short time-frame. > > And it is a single account, not the entire domain, that is the problem. > Or even a single message. And I've never understood why people get enamored of the idea of relying on bad reputations to spot bad actors. A bad actor who thinks it has attracted a negative reputation need only move to a new name in an otherwise gigantic public namespace (domain name or IP address) to start over from zero. > > Just use different domains / keys to indicate different things. > > > > No new standards. No new code. No new config. > > And no new information. Hence, current mechanisms only, which are not > all that successful for this problem. > This also presumes that operators currently develop reputation based on (d=, s=) pairs. Is that so? I thought it was mostly just the d= that matters. -MSK, participating ___ 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?
Sent from my iPhone > On 30 Aug 2023, at 03:38, Grant Taylor > wrote: > > On 8/29/23 3:15 PM, Steve Atkins wrote: >> Any attempt by senders to filter outbound emails based solely on content is >> going to have a lot of false negatives and positives, wherever you decide to >> draw the line. > > I find the idea of using different, probably less stringent, filtering on > outbound than on inbound to be hypocritical. You have much more data for inbound email, and access to a much wider range of reactions. That’s not “hypocritical”. The only information a sender has that a receiver doesn’t is a broader view of who the recipients of messages being sent are - and that’s exactly the information that DKIM replay hides from the sender. > > I find it tantamount to someone saying they only accept the most pristine > message while sending less pristine, and sometimes really tarnished, email. > > Sure, there are some differences, e.g. lack of user preferences. > > Why the asymmetry? > > Why not apply the same filtering for outbound messages as applied to inbound > messages? Because they’re quite different environments. > >> Inbound content-based filtering is much easier to get right - not least >> because the fallback is “just deliver it to the spam folder” - and we’re not >> great at that. > > I guess I'm coming from a different place. I always was more worried about > what I send and not upsetting the rest of the Internet than I am about what I > accept in. That’s not the issue. It’s much easier to filter inbound mail accurately than it is outbound mail. And we’re not great at filtering inbound mail. Cheers, Steve ___ 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 8/29/2023 7:46 PM, Grant Taylor wrote: On 8/29/23 9:02 PM, Dave Crocker wrote: Why not re-use the existing DKIM solution, just with a different domain / set of keys? Because it does not provide the affirmative information that I am postulating/guessing the originating platform can supply. Let a domain establish a bad reputation. Especially if it's being used for sending messages that are considered to be questionable. Establishing a reputation takes time. The likely behavior of a bad actor is within a very short time-frame. And it is a single account, not the entire domain, that is the problem. Plumbing historically has had clean water and waste water. The behavior of spammers is not as discrete or as stable as your example requires. 3. Receiving hosts can take this as a flag for extra caution. The damn thing still gets to victim platforms, but those platform have a bit more information to factor in. I feel like this falls back to a priming problem of who sends the flag because not enough people are checking for it and not enough people will check for it because not enough people are sending it. What's more is that this is going to be viewed as some as tantamount to $SO_AND_SO is sending $SPAM, see they even tag it as such. The nature of a collaborative mechanism is that, yes, both sides have to adopt it. Adoption takes time. The upside of the model I'm suggesting is that a) it's pretty cheap, and b) it's likely to be useful to a relatively, small set of very, very valuable domains. So it does not have to gain widespread adoption on the origination side, to be useful. DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and receivers opt in to use them. Both sides are necessary. So I'm wondering about looking for something the furthers the collaboration. Or re-use the existing systems that are already in place and being used by much of the email community. Just use different domains / keys to indicate different things. No new standards. No new code. No new config. And no new information. Hence, current mechanisms only, which are not all that successful for this problem. Maybe I'm too salty for the end of a long day, but I feel like this is in some ways "nothing new to see here, move along". That view has been constantly asserted here, by some folk. Why anyone believing that continues to participate in this effort is a mystery. 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] What makes this posting different from the original posting?
On 8/29/23 9:02 PM, Dave Crocker wrote: A possible way to think about how to approach this: 1. Use the mechanism for messages deemed spammy by the originating platform, or for new users who do not yet have an established quality record, or... 2. Add a header field that has semantics along the lines of "Yes I signed this and yes I sent it, but I'm not happy about it." Why not re-use the existing DKIM solution, just with a different domain / set of keys? Let a domain establish a bad reputation. Especially if it's being used for sending messages that are considered to be questionable. Plumbing historically has had clean water and waste water. Now -- what is called -- grey water is being used in some places in parallel to the other two. There is no false pretense that grey water is new nor waste. Grey water is it's own thing and it is treated as such. 3. Receiving hosts can take this as a flag for extra caution. The damn thing still gets to victim platforms, but those platform have a bit more information to factor in. I feel like this falls back to a priming problem of who sends the flag because not enough people are checking for it and not enough people will check for it because not enough people are sending it. What's more is that this is going to be viewed as some as tantamount to $SO_AND_SO is sending $SPAM, see they even tag it as such. DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and receivers opt in to use them. Both sides are necessary. So I'm wondering about looking for something the furthers the collaboration. Or re-use the existing systems that are already in place and being used by much of the email community. Just use different domains / keys to indicate different things. No new standards. No new code. No new config. Just a new domain / set of keys that need to establish a reputation, whatever that is. That's something that already happens day in and day out. And the attacker can't bypass it, if the signature covers enough (or all) of the message. Maybe I'm too salty for the end of a long day, but I feel like this is in some ways "nothing new to see here, move along". -- Grant. . . . unix || die ___ 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 8/29/23 3:15 PM, Steve Atkins wrote: Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. I find the idea of using different, probably less stringent, filtering on outbound than on inbound to be hypocritical. I find it tantamount to someone saying they only accept the most pristine message while sending less pristine, and sometimes really tarnished, email. Sure, there are some differences, e.g. lack of user preferences. Why the asymmetry? Why not apply the same filtering for outbound messages as applied to inbound messages? Inbound content-based filtering is much easier to get right - not least because the fallback is “just deliver it to the spam folder” - and we’re not great at that. I guess I'm coming from a different place. I always was more worried about what I send and not upsetting the rest of the Internet than I am about what I accept in. -- Grant. . . . unix || die ___ 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 8/29/2023 1:15 PM, Steve Atkins wrote: Many, many people sign up to receive content that is, by any objective content-filtering standard, as spammy as an incredibly spammy thing. Seriously, people sign up for things you would not believe. Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. So, what you say makes complete sense, of course. And yet, I suspect that this problem nonetheless requires active measures at that point in the handling sequence. The question, then, is what might help, without causing too much problem. My immediate thought is an overlay to DKIM. That is, an added mechanism that is protected by the DKIM signature. A possible way to think about how to approach this: 1. Use the mechanism for messages deemed spammy by the originating platform, or for new users who do not yet have an established quality record, or... 2. Add a header field that has semantics along the lines of "Yes I signed this and yes I sent it, but I'm not happy about it." 3. Receiving hosts can take this as a flag for extra caution. The damn thing still gets to victim platforms, but those platform have a bit more information to factor in. DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and receivers opt in to use them. Both sides are necessary. So I'm wondering about looking for something the furthers the collaboration. And the attacker can't bypass it, if the signature covers enough (or all) of the message. d/ 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] What makes this posting different from the original posting?
Sent from my iPhone > On 29 Aug 2023, at 20:54, Dave Crocker wrote: > > On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote: >> For (1), I presume the outbound site did not make a quality assessment that >> identified the message as "likely to be replayed". Does this reduce to the >> "don't sign spam" argument? > > I have no idea what the current levels of outbound filtering are, among major > platforms. If it ain't already very high, yeah, seems like it should be and > that this is an added incentive why. Many, many people sign up to receive content that is, by any objective content-filtering standard, as spammy as an incredibly spammy thing. Seriously, people sign up for things you would not believe. Any attempt by senders to filter outbound emails based solely on content is going to have a lot of false negatives and positives, wherever you decide to draw the line. Inbound content-based filtering is much easier to get right - not least because the fallback is “just deliver it to the spam folder” - and we’re not great at that. Cheers, Steve ___ 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 8/29/2023 12:30 PM, Murray S. Kucherawy wrote: For (1), I presume the outbound site did not make a quality assessment that identified the message as "likely to be replayed". Does this reduce to the "don't sign spam" argument? I have no idea what the current levels of outbound filtering are, among major platforms. If it ain't already very high, yeah, seems like it should be and that this is an added incentive why. 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] What makes this posting different from the original posting?
On Tue, Aug 29, 2023 at 11:10 AM Dave Crocker wrote: > Two thoughts: > >1. If the substance of the message should fail a quality assessment, >why does it pass at the outbound (sending) site? >2. If the problem is reasonable content, but sent to many unintended >(or, rather, undeclared) recipients, then the only characteristic of note >is the fact of multiple transmissions. So I'd guess it is only a real-time >network of receivers, working in /very/ close coordination, to detect and >deal with the attack. (it's not difficult to imagine scattered >retransmissions, over time, to hide the coordination. Sort of a spread >spectrum transmission style...) > > For (1), I presume the outbound site did not make a quality assessment that identified the message as "likely to be replayed". Does this reduce to the "don't sign spam" argument? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] What makes this posting different from the original posting?
Not that this is all that new a question, but I think it might be worthy of more (and maybe different focus)... When a message is used in a DKIM Replay Attack: 1. It originates from a domain name having good reputation 2. It passes quality checks from that sending domain 3. It goes to a collaborating receiving site, which presumably means that site is not conducting quality assessments 4. It is re-posted, preserving the original DKIM signature, but now becomes an attack Two thoughts: 1. If the substance of the message should fail a quality assessment, why does it pass at the outbound (sending) site? 2. If the problem is reasonable content, but sent to many unintended (or, rather, undeclared) recipients, then the only characteristic of note is the fact of multiple transmissions. So I'd guess it is only a real-time network of receivers, working in /very/ close coordination, to detect and deal with the attack. (it's not difficult to imagine scattered retransmissions, over time, to hide the coordination. Sort of a spread spectrum transmission style...) 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
