On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: > Sorry I'm late to this thread. > > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman <skl...@kitterman.com> > > wrote: > > I agree that we don't want too much detail in the charter about the > > technical > > nature of the problem, but I would like to understand it in more detail in > > order to better assess the appropriateness of what is there. > > > > If a domain is signing spam and their reputation suffers as a result, > > isn't > > that the system working as designed? > > > > I would like to understand what is the technical characteristic of these > > messages that is distinct from the non-bad ones. As far as I can tell > > (and > > this isn't the first time I've run across these discussions), there isn't > > one. > > If that's the case, then I don't think there's an actual technical > > solution to > > this problem. > > The slides > <https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim > -replay-problem-and-possible-solutions> at Dispatch and the problem > statement draft > <https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/> help > describe the DKIM replay problem.
I think this draft is very useful. I think it supports my contention that this problem is not technically distinguishable from legitimate mail flows. > There are some things that we could target at a technical level. We > probably would look for characteristics in the typical attack flow i.e. > After having a spammy message signed, the spammer typically copies a > message from the inbox, and then broadcasts it with a high degree of > amplification. We could look for > > - Messages that are sent to recipients that are not intended by the > original sender or the forwarder > - Messages may be viewed as traversing a path defined by the original > sender and forwarder. Messages taken from that intended path could be > replay > - A variation is: messages that are taken from the inbox and then resent > - Count the signatures seen and filter by count I think that between the draft and the discussion so far there are a few classes of potential solutions: 1. Signers have taken responsibility for the message when they signed it, so they get to live with the consequences of having done so (for this purpose, I think the "message" is the signed content of the message). No standards action or changes required to DKIM, except maybe modernizing header field signing/over-signing recommendations to make replay at least a little more difficult. 2. Introduce changes that break existing indirect mail flows. Standards actions needed. Senders and receivers both need to make changes. Standards actions needed. If we go down this path, would it be more honest just to declare indirect mail flows obsolete/deprecated (based on the prevalence of >From re-writing on mailing lists, common practice may be headed this way already due to DMARC). 3. Changes that modify expectations for legitimate indirect mail flows that illegitimate indirect mail flows such as replay attacks will have difficulty copying. These require changes by senders, indirect mail processors (e.g. mailing list providers and forwarders), and receivers. Unlikely to be effective until widely implemented. Are there more? > > Once work is chartered in the IETF, it tends to get a certain momentum > > toward > > producing a result. Before agreeing that we have a charter to solve a > > problem, I'd like to understand we have a problem that can be solved, even > > though that requires a bit of discussion at a more detailed level than > > what > > eventually goes in the charter. > > > > Leaving aside algorithms and processes for a moment, could someone > > describe > > how an technically proficient human would examine one of these messages > > and > > determine they are "bad"? > > What I've seen is that the Received header shows the delivery of the > message to the initial recipient, followed by a new set of Received headers > that shows that the message has been resent. Sometimes the spammer leaves > behind other clues like duplicate headers like multiple Date, Message-id or > Subject headers. None of these other clues need anything from DKIM to detect, although over signing such fields may help (no RFC is needed for this, senders can just do it, if it's useful). Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
