> On 6 Aug 2023, at 19:07, Jesse Thompson <z...@fastmail.com> wrote: > > On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote: >>> On 5 Aug 2023, at 02:43, Jesse Thompson <z...@fastmail.com >>> <mailto:z...@fastmail.com>> wrote: >>> >>> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote: >>>> I agree with this and have been working to recruit folks to come here. >>>> I’ll also be in Brooklyn and pitching the need for participation in the >>>> IETF working group from folks in the email space who are seeing issues >>>> with this. >>> >>> I'll be there and interesting in participating. As an ESP/infrastructure >>> provider I can say that we are "having" the issue, but can't say that we >>> "seeing" the issue since visibility is only available to anti-spammers, and >>> domain owners (who receive DMARC reports). >> >> A big driver of the work is actually Google. As I understand it, they are >> having issues because the replay attackers are successfully stealing >> reputation of otherwise good senders in order to bypass some spam filtering. >> The replay attackers aren’t sending what we commonly think of as spam >> through the signers - as the message is sent to one recipient (not bulk) and >> it is opt-in (that recipient wants and has asked for the mail). > > This is accurate from my observation. It takes only a single message which > evades content filters, and the attacker is the first recipient, who will not > report it as abuse. > > Which is why an earlier "just don't send spam" comment seemed to be > borderline FUSSP rhetoric. If the message isn't detected by the receiver (who > has the most visibility into the type of mail its users want to receive) then > how can a sender be held to a higher standard of detection with less > visibility?
I agree wholeheartedly. I just wanted to make it clear for the record that this isn’t an issue of the signer knowingly signing spam and “deserving” any reputation problems. > The reputation they are stealing is that of the DKIM domain(s) associated > with the signatures on the message (whether they are aligned to the > rfc5322.From or not). So, adding more signatures to convey more fidelity > would seemingly help solve the problem because receivers could better > fingerprint good patterns from bad patterns. But replayers could just remove > the higher fidelity signatures. > > To solve that, I think we need Mandatory Tags for DKIM Signatures [1] 3.3. > Forward signature (!fs) tag. > > [1] https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04 > 3.3. Forward signature (!fs) tag > The "!fs" mandatory tag means that the signature is only valid if an > additional signature is present in the message. The value of the !fs tag is a > domain name that is the value of the d= tag of the additional signature. The > condition is satisfied if the message includes at least one valid DKIM > signature header field with responsible domain (the d= tag) being one > specified by the !fs tag. Chained !fs tags are valid and may be useful in > scenarios with multiple levels of forwarders. DKIM verifiers SHOULD handle at > least three levels of !fs chaining. I’ll have to read that more fully, but a brief read through seems to indicate this isn’t the solution to the replay problem. To whit: "6. Security Considerations It opens up a variety of obvious replay attacks that may or may not be important depending on both the selection of target domains for messages to be forwarded, and the behavior of forwarders that receive messages with conditional signatures.” Also, I’m not sure how it will work on mail that isn’t expected to be forwarded. >>> I recall various assertions that the reason why DMARC has been successful >>> is primarily because of the Reporting benefits (and I certainly agree with >>> this assertion from my background as an enterprise domain owner), while the >>> Conformance benefits seem to be more elusive (as evidenced by the >>> inconsistent adoption by receivers and the debates around interoperability >>> issues with indirect mail streams). Of course, the Authentication benefits >>> are provided by DKIM/SPF, and yet DKIM signers have no standard mechanism >>> to receive reports of how their signatures are being misused. >>> >>> If people think that Reporting is the reason why DMARC has been successful, >>> then could we conclude that the lack of Reporting to DKIM signers is a >>> problem worth addressing? >> >> That’s an interesting thought. I’m thinking the next step down - will it >> help minimize the problem for senders? ie, would reporting be fast enough >> that they could revoke a key? > > The reason why key revocation doesn't work today (other than DNS TTL) is > because the replayed keys are in domains that too broadly cover desirable > mail. The key which should be revoked should be the one that most narrowly > stops only the replayed mail and not stop otherwise good mail. In the > high-fidelity multi-key model with forward signature tags, revocation of a > single key to break the chain seems possible. How quickly it can be done is > lower bound to how quickly a receiver's reputation algorithms can identify > fingerprint any message down to the highest fidelity key, but the risk of DOS > implies there needs to be some kind of moderation. Are you suggesting individual signatures for each recipient domain? > I think the DNSxL approach is more flexible and timely than revoking the key > from DNS. So, while anti-spammers are in a better position to create and > maintain DNSxLs for thwarting replay attacks, I was thinking about a model > where ESPs index customers with DKIM signatures in domains that are unique > per customer, or perhaps even more granular. No customer information is > otherwise provided. The domains are listed in various DNSxLs hosted by the > ESP which are easily queryable via DNS lookups. Each DNSxL conveys a specific > meaning (typically leaning more in the "allow" than "block" part of the > spectrum), as defined by the ESP. Mail receiving organizations may choose to > incorporate querying these DNSxL lookups into their mail filtering and > un-modification algorithms as they deem appropriate. I reference > un-modification because I think it can be adapted to fit with Wei's > Tolerating Mailing-List Changes draft, and expand the scope to "Tolerating > Modifications and Non-Authenticatable Mail From Reputable Intermediaries and > Sending Providers" I’m not sure asking for more work from third parties (the DNSxL maintainers) is a viable long term solution. We know there are spam gangs that focus on one or two domains. Those domains may consume DNSxL data, but do they send data back to the DNSxL? >> What might a report look like? > > I guess the format and the information in DMARC reports would be a good place > to start the discussion, with some tweaks for forward signature info, and > privacy and DOS considerations. The typical once/day timeliness of DMARC > reports is probably not fast enough to stop an active replay, but good enough > for an ESP to remove the bad actor and introspect about how to detect and > prevent future occurrences. Yeah, I think that’s the real issue here. As I understand it the attacks are fast - sometimes a few hours from the original message and the replay with everything being over in <24 hours. If my understanding is correct anything we do needs to be handled in a time sensitive manner. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
