Re: [Ietf-dkim] Replay Attack vs. something else
On 3/22/23 6:00 PM, Scott Kitterman wrote: That's my understanding, however that scenario also describes a normal mailing list if it doesn't make modifications that break an existing DKIM signature or any kind of forwarding with similar characteristics. The issue has little to do with the originating domain. It has to do with piggy-backing off of the reputation off of a domain regardless of who originated it. It's probably the easiest to do that with the originating domain, but that doesn't mean it can't be done elsewhere. Indeed, the bulk sender signing from their own domain instead of the originating domain is essentially the same as the mailing list problem. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay Attack vs. something else
On Wednesday, March 22, 2023 8:21:55 PM EDT Dave Crocker wrote: The scenario is re-posting a message such that the original DKIM signature remains valid. Any other sort of re-posting does not qualify, under this definition. So, for example, anything depending on 're-signing' is not a DKIM Replay Attack. Yes? That's my understanding, however that scenario also describes a normal mailing list if it doesn't make modifications that break an existing DKIM signature or any kind of forwarding with similar characteristics. Indeed. Noting that benign re-postings look the same would be a requirement for the PS. (As the current and future drafts do.) 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] Replay Attack vs. something else
On Wednesday, March 22, 2023 8:21:55 PM EDT Dave Crocker wrote: > My understanding is that the term DKI MReplay Attack refers to a very > specific scenario. > > The scenario is re-posting a message such that the original DKIM > signature remains valid. > > Any other sort of re-posting does not qualify, under this definition. > > So, for example, anything depending on 're-signing' is not a DKIM Replay > Attack. > > Yes? That's my understanding, however that scenario also describes a normal mailing list if it doesn't make modifications that break an existing DKIM signature or any kind of forwarding with similar characteristics. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] Replay Attack vs. something else
My understanding is that the term DKI MReplay Attack refers to a very specific scenario. The scenario is re-posting a message such that the original DKIM signature remains valid. Any other sort of re-posting does not qualify, under this definition. So, for example, anything depending on 're-signing' is not a DKIM Replay Attack. Yes? d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Welcome to the rechartered working group
On 3/22/23 4:00 PM, Emanuel Schorsch wrote: On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy wrote: On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch wrote: In my mind, there are two important things I would like to see achieved: 1) Distinguish indirect from direct flows (encode in some way which server / mailingList the original DKIM message was intended to come from). This is needed for domains that aren't easily identifiable as direct flows (SPF isn't aligned by DKIM in the direct case). Wasn't ARC meant to solve this? What have the results been? ARC has the same challenge that DKIM has when it comes to replay. How do I know if this is direct mail or indirect mail? Which set of IPs should I expect the direct mail to be sent from? ARC allows forwarders to record/preserve authentication status but the same valid ARC headers can be sent millions of times from all kinds of different servers. Note that DKIM has been able to sign auth-res from the very beginning. Which is why ARC getting inserted into discussions like this is both frustrating and just muddies the waters. 2) Give more info to identify benign indirect flows (E.g. "forwarded on behalf of"). This is helpful for recognizing a recipient's desired indirect flows. I'm pretty sure this is easily spoofed. So is any sort of tagging or header field manipulation mechanism. The spammer just needs to make its mail look sufficiently like something you consider legitimate, and they're in. That is why it would be nice to see a solution less trivially spoofable than existing forwarding headers (e.g. X-Forwarded-For). If, for example, forwarded-for is recorded in the ARC header, then you can restrict yourself to trusting a specific pair of "forwarded-for" and ARC sealer, which is much more trustworthy than the header alone. But, even an easily spoofable header is still useful. Easily spoofable means that it doesn't provide much protection against phishing, but it does make it substantially harder to scale for spam. Most people will have a limited set of sources which they receive indirect mail for, and those will vary widely between people. So if spammers, for the Forwarded-For header, need to get the right value per recipient it makes automating to a huge scale much more difficult. But the spammer can also resign a message to make it look like an indirect flow along with whatever headers you insert. In the end this all boils down to how much you trust the domain sending you the message. For the domain the spammer controls, you'd hope they have a neutral to bad reputation. For legit mailing list providers, you'd hope they would get a positive reputation over time. None of this has anything to do with the problem that ARC purports to solve. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Welcome to the rechartered working group
On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy wrote: > On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch 40google@dmarc.ietf.org> wrote: > >> In my mind, there are two important things I would like to see achieved: >> >> 1) Distinguish indirect from direct flows (encode in some way which >> server / mailingList the original DKIM message was intended to come from). >> This is needed for domains that aren't easily identifiable as direct flows >> (SPF isn't aligned by DKIM in the direct case). >> > > Wasn't ARC meant to solve this? What have the results been? > ARC has the same challenge that DKIM has when it comes to replay. How do I know if this is direct mail or indirect mail? Which set of IPs should I expect the direct mail to be sent from? ARC allows forwarders to record/preserve authentication status but the same valid ARC headers can be sent millions of times from all kinds of different servers. > > >> 2) Give more info to identify benign indirect flows (E.g. "forwarded on >> behalf of"). This is helpful for recognizing a recipient's desired indirect >> flows. >> > > I'm pretty sure this is easily spoofed. So is any sort of tagging or > header field manipulation mechanism. The spammer just needs to make its > mail look sufficiently like something you consider legitimate, and they're > in. > That is why it would be nice to see a solution less trivially spoofable than existing forwarding headers (e.g. X-Forwarded-For). If, for example, forwarded-for is recorded in the ARC header, then you can restrict yourself to trusting a specific pair of "forwarded-for" and ARC sealer, which is much more trustworthy than the header alone. But, even an easily spoofable header is still useful. Easily spoofable means that it doesn't provide much protection against phishing, but it does make it substantially harder to scale for spam. Most people will have a limited set of sources which they receive indirect mail for, and those will vary widely between people. So if spammers, for the Forwarded-For header, need to get the right value per recipient it makes automating to a huge scale much more difficult. > -MSK > ___ > 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
On 3/21/23 8:01 PM, Murray S. Kucherawy wrote: There was one prior answer to this. Here's another. There's a claim here that the problem statement(s) is/are too vague. I'm a little worried that tightening up the problem definition along these 20 vectors will give us such a tight problem statement that any solution is so targeted as to be of limited value. The sweet spot we're looking for probably lies somewhere in between. I wasn't intending for these to necessarily be inserted verbatim, but more to create a narrative of what is known and what is not known. I suspect that quite a lot is known even if it may not be public. It's rather useless to consider solutions that are known to not work or be insufficient, so adding them to the problem statement in enough specificity seems like a good way to stop going down rat holes later. On Fri, Feb 17, 2023 at 11:11 AM Michael Thomas wrote: I've said in multiple threads that the current problem both in the charter and the problem draft are far too vague for us to address. Here are some from me at least: 1. Who are the victims? Just bulk senders? Are the bulk senders signing using their domain? In my view, there are two: The receiver of the unwanted spam (that might not otherwise have been delivered), and the owner of the domain whose signature got replayed as it might now suffer a degraded reputation. But is, say, gmail or another large mailbox provider subject to the signing part of the attack, or is it mainly bulk senders? Also: I assume that enterprise, etc is not really affected by this. The current problem draft is pretty vague about who suffers from replay attacks and thus who should care about it. Also: reputation begs the question of *whose* reputation. If a bulk sender uses delegated keys from some other domain, it becomes the other domain's problem not the bulk sender. 1. Do senders filter outbound traffic for spam? I think it's safe to assume that the case we're most interested in does do this, but it seems to me that irrespective of the answer, the attack is working. The reason I ask is actually that if they filter outbound and they are seeing spam from an account, that is obviously suspicious. Doubly so for new accounts. 1. What are the characteristics of the spammer wrt to the sending domain? Are they brand new accounts or established ones? This one I don't have a guess about. I would say "either". Does this need to be known, or does it need to constrain the problem definition? Insofar as the output of the wg is to create a BCP instead of a protocol change, yes we'd need to know what is being done to prevent it currently. 1. Do sending domains keep track of users who are sending spam in the eyes of their filters? Do they correlate that with other characteristics of their users such as freshness? Also "either". 1. Do senders pay any attention to the To domain? I can't imagine this being valuable signal, given the additional use of various other address fields. 1. Do receivers pay attention to the To domain(s)? Same. In the case of a bulk sender, crafting a message to new or likely disposable domain might be considered suspicious. It is the essence of the attack, after all. If those senders can police that, that makes the attack all the more difficult to pull off. In the end, there is a business relationship between bulk senders and the spammer abusing them. That gives them more control than say a mailbox provider. As in: why are you sending to no-name domain from a bulk sender? 1. Does the To domain spammers use remain more or less static, or do they mutate at a high rate? The "To" field, or the RCPT TO(s) in the envelope? It seems like the To field (if signed) never changes, or it's whatever the spammer wants it to be if it's not signed. In the latter case, it's easy to make "To" and RCPT TO match, thwarting that check. The 822.To. Do we need to know this to define the problem space? Again, BCP, BCP, BCP. 1. Can filters be adjusted at a more fine grain in the face of different conditions? That is, accept a higher false positive rate in certain conditions? This seems to me to be part of the answer we might provide rather than part of the problem definition. Again, we either find out now or we are doomed to ask about it later. Part of the meta problem with this wg is what is available in public vs. what is proprietary or not for public consumption. 1. Do receivers use things like unsigned Subject or To or other tell-tale fields as signs of a bulk replay? I don't think they've ever been specifically associated with replay, but an unsigned Subject was held up even in the early DKIM days as the sort of thing about which a receiver might exercise its discretion to invalidate a signature. The Authentication-Results RFC introduced the term "acceptable
Re: [Ietf-dkim] Clarifying the problem
On 3/22/2023 11:22 AM, Murray S. Kucherawy wrote: Do you believe knowing the answer to this question would allow us to amend the problem statement to something that might allow a protocol solution? That sounds reasonable. However it might actually represent scope-creep for a Problem Statement document. I'd expect a PS doc to be required to describe... the problem. The problem is what we understand of what is happening. At it's core, that's one paragraph of text. It's possible to turn this into a large research problem, in order to discern all of the fine-grained details and corner-cases. That seems an IRTF task, not a WG task. For a WG, it seems best to have pretty much what we already have -- Wei is working on a revision -- which provides a working definition of a DKIM Replay Attack. More in aid of recruiting participation than to satisfy an actual requirement, it might help to have some general discussion of operational issues, and broad strokes of current thinking about solutions. But again, that's for extra credit. It would, after all, be nice to move from PS discussions to, you know, talk about remedy and maybe prevention paths. 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] Clarifying the problem
On 3/22/23 12:57 AM, Evan Burke wrote: 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. The reason I ask is because if it's uncommon to not provide unsubscribe links, that's a signal that something might be wrong. That's especially true for bulk senders who could/should require valid unsubscribe links. Now whether that's hard to police is another matter, but it would be good to get that out in the open. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Welcome to the rechartered working group
On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch wrote: > In my mind, there are two important things I would like to see achieved: > > 1) Distinguish indirect from direct flows (encode in some way which server > / mailingList the original DKIM message was intended to come from). This is > needed for domains that aren't easily identifiable as direct flows (SPF > isn't aligned by DKIM in the direct case). > Wasn't ARC meant to solve this? What have the results been? > 2) Give more info to identify benign indirect flows (E.g. "forwarded on > behalf of"). This is helpful for recognizing a recipient's desired indirect > flows. > I'm pretty sure this is easily spoofed. So is any sort of tagging or header field manipulation mechanism. The spammer just needs to make its mail look sufficiently like something you consider legitimate, and they're in. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Clarifying the problem
On 3/22/23 11:22 AM, Murray S. Kucherawy wrote: On Tue, Mar 21, 2023 at 8:37 PM Scott Kitterman wrote: >> 1. Do receivers keep tabs on which users are using things like >> mailing lists to differentiate users who expect to get indirect mail vs >> those who don't? >> >> The large mailbox operators might have hints about this, but I'm not sure >the answer would serve to further constrain the problem statement. I think it relates to the largest challenge to the problem statement: what distinguishes these 'bad' messages from 'good' indirect mail flows such as mailing lists. As far as I can tell, the answer is nothing, which leaves it challenging to produce an effective protocol change which addresses replay that doesn't also have substantial side effects on non-replay traffic. I agree, but: Do you believe knowing the answer to this question would allow us to amend the problem statement to something that might allow a protocol solution? My point is that I don't think it would. The charter leaves a BCP-like document in scope as a possibility. For a BCP, you need to know what the state of art is, obviously. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Clarifying the problem
On Tue, Mar 21, 2023 at 8:37 PM Scott Kitterman wrote: > > >>1. Do receivers keep tabs on which users are using things like > >>mailing lists to differentiate users who expect to get indirect mail > vs > >>those who don't? > >> > >> The large mailbox operators might have hints about this, but I'm not > sure > >the answer would serve to further constrain the problem statement. > > I think it relates to the largest challenge to the problem statement: what > distinguishes these 'bad' messages from 'good' indirect mail flows such as > mailing lists. As far as I can tell, the answer is nothing, which leaves > it challenging to produce an effective protocol change which addresses > replay that doesn't also have substantial side effects on non-replay > traffic. > I agree, but: Do you believe knowing the answer to this question would allow us to amend the problem statement to something that might allow a protocol solution? My point is that I don't think it would. -MSK ___ 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
