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
