Re: [Ietf-dkim] replay clues
On 2/11/2023 4:48 PM, Stephen Farrell wrote: asking good questions that deserve consideration. Steve, There is a draft problem statement that seeks to explore the problem space. Perhaps you can suggest specific additions to it that should be made and fleshed out? That is, after all, the usual way working groups try to work, even before being chartered. One of the challenges in considering email abuse 'clues' is distinguishing between ones that are inherent and of longer-term benefit to consider, versus those that might be of very transient benefit or, worse, appear in all sorts of different traffic, and possible good or bad traffic at that. Standards work is slow and expensive and therefore really ought to limit itself to things that will be of longer-term benefit. There is a very serious potential of chasing squirrels and/or trying to boil the ocean. It's easy to raise possibilities, and difficult to raise good ones. 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 clues
Hiya, FWIW, as this discussion has a bit of a flavour of one person arguing with a bigger bunch of people, I'd like to say that Mike is asking good questions that deserve consideration. I don't have a position as to what may or may not be worth doing in this space, but I figure I'll find it easier to arrive at my own position after Mike's questions are worked through. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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/10/23 9:36 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 12:06 PM Evan Burke wrote: On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote: On 2/10/2023 11:35 AM, Wei Chuang wrote: > ARC is a tool to help support modern Indirect Mail Flows, and I > believe belongs in the solution space to be explored. Since ARC uses the same technology as DKIM and uses it in pretty much the same was, my understanding is that it, too, has the potential for replay. Having a reference to this fact makes sense to me. It doesn't need more than a mention, at this point, I believe, which makes the current quick, reference exactly the right text, IMO. +1 I realize there are some mixed opinions on ARC, but it's actively used on several of the world's largest email systems - some of the same ones where DKIM replay attacks are focused - so it's worth consideration as part of the solution space. It may not end up being a viable option, but now isn't the time to write it off. Speaking only as a participant: I also don't think a comment like "ARC has the same problem, for largely the same reasons" is by itself harmful here. What I think we should be sure to avoid is expending WG energy trying to solve this problem in ARC-space. That, I would argue, is outside the charter. I see that they took out a lot of other mentions in this rev, but I have a real problem with editorializing that ARC does this or ARC does that which is to say the least, controversial. It's really not germane to this wg and imo the easiest thing to do is nothing at all wrt ARC. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] replay clues
On 2/10/23 9:23 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: I've always thought that the likelihood of a protocol level solution for this issue is pretty close to zero if not zero. The various proposed solutions in the problem draft haven't given me any reason to dissuade me of that notion. That said, I think that we might be able to catalog some clues that something is suspicious which taken with many other clues can be used to by a receiver to make an ultimate decision of spamminess. A good example is the unsigned To: and Subject: lines. Even if it's strictly allowed by the spec, that doesn't mean it's not suspect. It could be really useful to collect this clues as input signals to a larger preponderance of evidence. Authentication-Results already noted the idea that a signature, even a valid one, might still be considered not acceptable to the verifier and reported differently for one reason or another. An unsigned Subject was the classic example. Dealing with this in A-R nicely removes it from being dealt with at the protocol level, where I would argue this sort of logic doesn't belong. It's never been especially clear to me whether deployments do their filtering up front, ie at the MX, or farther down the line. There are certainly advantages to do it right at the MX with less burden on using AR to signal all of what the filters consider the interesting bits that standard A-R might not support. But there may be good architectural reasons to postpone the filtering to later in the pipeline even if means that you're holding the spam longer before discarding it. But regardless of A-R just cataloging what those interesting bits might be could be useful in documenting how they can be used to detect replay spam. Also: I think there is more to it than whether the signature verifies, per say. The signature actually verifies, but it's the scrutiny that matters. Saying it doesn't verify essentially decouples from any reputation of the domain. But that is hardly the only way to look at it. Saying it verifies, but has problems is another way to view it. For wetware investigators an A-R that did that could be really confusing. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
