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
