On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman <[email protected]> wrote:
> On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: > > 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. > > I think this draft is very useful. I think it supports my contention that > this problem is not technically distinguishable from legitimate mail flows. > > > 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 > > I think that between the draft and the discussion so far there are a few > classes of potential solutions: > > 1. Signers have taken responsibility for the message when they signed it, > so > they get to live with the consequences of having done so (for this > purpose, I > think the "message" is the signed content of the message). No standards > action or changes required to DKIM, except maybe modernizing header field > signing/over-signing recommendations to make replay at least a little more > difficult. > > 2. Introduce changes that break existing indirect mail flows. Standards > actions needed. Senders and receivers both need to make changes. > Standards > actions needed. If we go down this path, would it be more honest just to > declare indirect mail flows obsolete/deprecated (based on the prevalence > of > >From re-writing on mailing lists, common practice may be headed this way > already due to DMARC). > > 3. Changes that modify expectations for legitimate indirect mail flows > that > illegitimate indirect mail flows such as replay attacks will have > difficulty > copying. These require changes by senders, indirect mail processors (e.g. > mailing list providers and forwarders), and receivers. Unlikely to be > effective until widely implemented. > Are there more? > A way of bridging this, particularly for approach 3, is to use legacy authentication in addition to the replay resistant technique. Use the replay resistant technique when available in preference to DKIM for DMARC and reputation systems, but have it available to fall back to. A follow on consideration then is why would anyone adopt the new replay resistant technique. Presumably there would be deliverability incentives for senders and forwarders to adopt the replay resistant technique (due to the negative reputation effects DKIM replay has) and for receivers to avoid escalations. In any case, I think the above categorization is pretty reasonable. > > > 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. > > None of these other clues need anything from DKIM to detect, although over > signing such fields may help (no RFC is needed for this, senders can just > do > it, if it's useful). > Received headers are generally not DKIM signed and spammers have stripped/probably modified them. Another problem is that while a human can interpret the domain names, IP and other information present there in the headers, the non-standard naming and format variations means that it's not suitable as a machine readable signal in my opinion. -Wei > Scott K > > > _______________________________________________ > 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
