Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman wrote: > Currently RFC 6376 says, "Signatures MAY be considered invalid". I think > the practical effect as described in protocol terms would be to change the > MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not > that I'd expect to see this appear in a protocol document (maybe some kind > of applicability statement). > Beyond this SHOULD, I think we need to consider whether the caller needs to be told specifically when a failure occurs for this reason. Right now an implementation might return just a PERMFAIL without noting that it's because of "x=" versus the signature failing for some other reason. Should the caller be given this extra detail to enhance the decision tree, or will this just complicate things? I think, for instance, libopendkim does identify the reason for the failure, but I'm not sure whether any consumers of that API make use of that detail beyond maybe logging it. -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 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
[Ietf-dkim] Clarifying the problem
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? 2. If there are different types of senders who suffer from replay attack reputation, are the attacks using the same or different techniques to create the signed spam? 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? 5. What are the characteristics of the spammer wrt to the sending domain? Are they brand new accounts or established ones? 6. 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? 7. Do senders pay any attention to the To domain? 8. Do receivers pay attention to the To domain(s)? 9. Does the To domain spammers use remain more or less static, or do they mutate at a high rate? 10. Can we quantify the reputation bump (or hit) on the receiver from these spam bursts? (I'm sure the spammers know the answer to this) 11. Do spammers with a replay server sign and/or set up SPF records for their spam sending domain? 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? 14. 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? 15. Are there receivers out there that treat an x= expired message different than a missing or broken signature? It's ambiguous in the DKIM text about that, I think. 16. Can receivers take advantage of the signalling of a small x= value as also a clue that the sender is concerned about replays? 17. Do receivers use things like unsigned Subject or To or other tell-tale fields as signs of a bulk replay? 18. Do receivers collect and use reputation information on mailing lists and other indirect flows that resign their messages? 19. What percent of incoming email to a mailbox is through resenders and of that what percent resign? 20. 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? I know that some of these have been answered to some degree or another, but wanted to put them in one thread so they can be added to the problem draft easier as needed. Also: to the degree that some of these questions can't be answered or only very vaguely is its own answer as to what this wg can and can't do. Some might be just nice to have, but some might be more foundational. Feel free to add to my list because I'm sure it's far from comprehensive. 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 2/17/23 9:34 AM, Scott Kitterman wrote: Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not that I'd expect to see this appear in a protocol document (maybe some kind of applicability statement). It does create a circumstance where indirect mail flows look inherently less good (since they take longer), which I don't like. On the other hand, if X is set more than a minute or so in the future, mostly what is affected is mail that is delayed in transit, direct or indirect and maybe that's okay. I think that the bulk senders who would be dialing down x= are not particularly worried about being sent through mailing lists. 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. 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
Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not that I'd expect to see this appear in a protocol document (maybe some kind of applicability statement). It does create a circumstance where indirect mail flows look inherently less good (since they take longer), which I don't like. On the other hand, if X is set more than a minute or so in the future, mostly what is affected is mail that is delayed in transit, direct or indirect and maybe that's okay. Scott K On February 17, 2023 5:22:37 PM UTC, "Murray S. Kucherawy" wrote: >On Thu, Feb 16, 2023 at 2:13 PM 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. >> > >One thing that would impede the success of this approach is whether current >implementations make the distinction between "invalid" and "valid but >expired", and for those that do not, how much churn and for how long it >would take to make that change to the ecosystem. > >-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 Thu, Feb 16, 2023 at 2:13 PM 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. > One thing that would impede the success of this approach is whether current implementations make the distinction between "invalid" and "valid but expired", and for those that do not, how much churn and for how long it would take to make that change to the ecosystem. -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 Thu 16/Feb/2023 21:56:52 +0100 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. Wouldn't it be possible to organize a gap-discovery scenario where the sender stores a per-user table of delivery times. One could get timings from positive DSN when available. Or one could create a new selector for each discovery, and measure the time between sending and the last DKIM key lookup. For domains who re-sign before forwarding (perhaps using ARC), and are trusted by their forwardee, it can be enough to store a per-domain entry, which is much more practical. It could be worth to add min/ max/ avg time entries to the layout of aggregate DMARC reports. (But this is the wrong mailing list to propose it.) Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
