Sorry I'm late to this thread. On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman <[email protected]> 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? > > 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. > The slides <https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim-replay-problem-and-possible-solutions> at Dispatch and the problem statement draft <https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/> help describe the DKIM replay problem. There are some things that we could target at a technical level. We probably would look for characteristics in the typical attack flow i.e. After having a spammy message signed, the spammer typically copies a message from the inbox, and then broadcasts it with a high degree of amplification. We could look for - Messages that are sent to recipients that are not intended by the original sender or the forwarder - Messages may be viewed as traversing a path defined by the original sender and forwarder. Messages taken from that intended path could be replay - A variation is: messages that are taken from the inbox and then resent - Count the signatures seen and filter by count 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"? > What I've seen is that the Received header shows the delivery of the message to the initial recipient, followed by a new set of Received headers that shows that the message has been resent. Sometimes the spammer leaves behind other clues like duplicate headers like multiple Date, Message-id or Subject headers. -Wei > 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 <[email protected]> > 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 <[email protected]> > 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 > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/ietf-dkim > > > > > > > > _______________________________________________ > > > > Ietf-dkim mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/ietf-dkim > > > > > > _______________________________________________ > > > Ietf-dkim mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/ietf-dkim > > > > > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
