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. 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"? I'll think about what else needs to be there from a compatibility perspective. I need to re-read the drafts and think about it first. Scott K On Thursday, November 10, 2022 5:35:08 AM EST Barry Leiba wrote: > We could add a sentence or two that says we’re seeing increasing spam > campaigns that use DKIM replay to get their spam sent out, taking advantage > of — and subsequently damaging — the reputation of the domain that signed > the original message. Do you think that would be useful? > > More detail than that doesn’t belong in the charter. I would expect to put > more detail in the Introduction section of the document we come up with. > > The “compatibility” part of the charter, and the discussions of what the > ultimate solution will be, will be what handles the “not breaking email > architecture” and minimizing damage to legitimate email flows. I don’t > think more of that detail needs to be in the charter either, but if you > disagree please suggest specific text you’d like to see. > > Barry > > On Wed, Nov 9, 2022 at 7:56 PM Scott Kitterman <skl...@kitterman.com> wrote: > > I think having a precised understanding of the problem that the charter is > > meant to address is important. I am having a hard time finding a > > technical > > distinction between a "replay attack" and the, by design, nature of DKIM's > > independence from transport details. > > > > I have not read all the drafts, but the ones I have looked at seem to want > > to > > tie some aspect of a DKIM signature to something in the envelope. I think > > that would be a 5321/5322 layering violation that would make such > > proposals > > difficult for protocol based systems to implement. > > > > I think there needs to be something about not breaking the architecture of > > email in the charter based on what I've read so far, but I don't think I > > have > > a fine enough understanding of the problem yet to propose words. > > > > Understanding and bounding the problem is, I think, an essential > > prerequisite > > to the charter. We've seen efforts fail before due to a lack of consensus > > on > > the exact problem (DBOUND comes immediately to mind). > > > > Even if there's no report, I think we should make sure we understand the > > problem first. > > > > Would someone who's pushing for a solution please describe what's being > > done > > that's technically distinguishable from something like traditional email > > forwarding (e.g. using may alumni.example.edu address and then > > alumni.example.edu forwards it to my current "real" address). By design, > > DKIM > > has no problem with this behavior, so I'd like to understand how to > > distinguish good from bad in this space. > > > > Scott K > > > > On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote: > > > Is this relevant to the charter? Do you doubt the attacks > > > sufficiently that you would want to object to chartering a working > > > group to address the issue? > > > > > > Barry > > > > > > On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely <ves...@tana.it> wrote: > > > > On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote: > > > > > [...] > > > > > > > > > > Current proposals include the following drafts: > > > > > - draft-bradshaw-envelope-validation-extension-dkim > > > > > - draft-chuang-replay-resistant-arc > > > > > - draft-gondwana-email-mailpath > > > > > - draft-kucherawy-dkim-anti-replay > > > > > > > > > > The working group will start by considering those proposals; other > > > > > proposals remain welcome. > > > > > > > > Isn't there a report on relevant replay attacks? All the above I-D > > > > say > > > > that replay attacks are a problem. Bron adds that the attack was > > > > widely > > > > > > seen in early 2022. However, there's not a panoramic view of the > > > > problem, mentioning volume, scope, targets and such. > > > > > > > > I know replay attacks are possible, but I never saw one. > > > > > > > > > > > > Best > > > > Ale > > > > -- > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ietf-dkim mailing list > > > > Ietf-dkim@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ietf-dkim > > > > > > _______________________________________________ > > > Ietf-dkim mailing list > > > Ietf-dkim@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf-dkim > > > > _______________________________________________ > > Ietf-dkim mailing list > > Ietf-dkim@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
