On Thursday, November 10, 2022 7:54:25 AM EST Murray S. Kucherawy wrote: > On Thu, Nov 10, 2022 at 12:42 PM 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? > > For cases of very large operators, like Gmail, their reputation doesn't > suffer to the extent that their mail becomes untrusted. The abuser thus > has a very long runway before something like that could start to happen. > > > 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. > > It may or may not be possible to reduce it to a technical characteristic. > However, the attack amounts to a Trojan horse whose distribution is enabled > or increased by DKIM; who's to say malware can't be sent this way? In my > view, that makes it something worth attention.
I agree it's worth attention, but let's make sure we understand the problem precisely enough to determine if we've succeeded. > > 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. > > I think of the charter as the contract between the working group and the > IESG that constrains what it will produce. The questions you're asking > here tend to be the things we ask in the discussion around the charter, > particularly during a BoF session to discuss working group formation, but > not necessarily what goes in the charter directly. > > So I think your question is a legitimate one, but I'm not sure what text > the charter ought to contain in order to address it directly. Thanks. I think this is a useful discussion and we'll probably know the answer to the question by the time we get to the end of it. > > 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"? > > The message itself is usually indistinguishable between its first instance > (when it's signed) and its second (when it's replayed). The envelope, > however, has to vary; that's a key property of the attack. One possible > solution is to come up with a scheme that factors that part of the envelope > into DKIM's operation; another is to pack useful metadata into the message, > independent of DKIM, so a downstream receiver stands a chance of telling > the difference between a first instance and a replayed instance. Which of > those two approaches should be used, and the exact mechanism of doing so, > would be the output(s) of this working group. This is helpful. It does highlight the architectural concerns I have. First, as in the alumni address example I gave, the envelope varying is a part of normal, legitimate email flows. If we are not careful, we'll recreate all the architectural limitations of SPF. You could, in fact, fairly trivially solve this problem in DMARC by creating a new alignment type which requires both DKIM and SPF to pass. That would have interoperability problems, but I think anything this group might develop ought to be notably more consistent with backward compatibility than that would be. Not for the charter, but it might be a reasonable benchmark to consider for determining if we've succeeded. Second, what you're suggesting as a possible class of solution involves taking information from the envelope and including it in the body. Because the Mail From, for example, isn't always known prior to submission, you might end up having to modify the body of the message somewhere between the Mail From command and Data in the SMTP session. This seems like a risky mixing of 5321 and 5322 functions. I have no idea how I would implement it. Let me think about what charter suggestions I have based on this. Thanks, Scott K _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
