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. 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. > 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. -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
