Re: [Ietf-dkim] Replay attack definition discussion
On Sun, Aug 20, 2023, at 6:13 AM, Alessandro Vesely wrote: > On Fri 18/Aug/2023 12:21:31 +0200 Emanuel Schorsch wrote: > >> > >>> For example, we have seen very large DKIM Replay attacks of youtube.com > >>> Terms of Service emails. There is no malicious content in these emails, > >>> but spammers still send very large volumes (perhaps using them to > >>> generate affinity with victims or warm up their sending > >>> infrastructure). >> > >> That points to a bug in the I-D. Section 3.1 says: > >> > >> A spammer will find a mailbox provider with a high reputation and that > >> signs their message with DKIM. The spammer sends a message with spam > >> content from there to a mailbox the spammer controls. > >> > >> Youtube.com Terms of Service emails don't seem to have been sent by the > >> spammer. > > > > I agree, for completeness we should update that section to include both > > types of DKIM replay. I can work on sending a tweak to that section. > > > Please do! Without it, Section 5.3, "Strip DKIM signatures on mailbox > delivery" makes little sense. > > > > But, to be clear this type of replay is definitely much less common than > > the spammer generated content. I just wanted to provide that it does also > > happen. > > If there is a large difference, then the idea of segmenting authentication > domains might actually belong to countering replay attacks, for spammers > looking for high reputation signatures. Some time ago I proposed > d=bullshit.example.com, but after thinking a bit more, the I-D could set up a > register for that. > > For a strawman: > >5.6. Use segmented signature domains > > Domains that host mailboxes for widely different categories of users, > typically free-mail domains, can differentiate the signature they affix > on messages by using subdomains. IANA maintains a register of > subdomains > used for this purpose (See Section 7.) > > * Messages written by spammers who get categorized as such will be > signed by subdomains with low reputation, which lowers the incentive > to obtain the very signature. > > * Careful users, who don't spam and don't have their accounts often > compromised, can use domains whose reputation won't be ruined by > replay attacks. > > And > >7. IANA Consideration > > This document proposes the use of subdomain to categorize email message > categories for which IANA is to create and maintain a new registry > entitled "DKIM Semantic Subdomain Names". > > New registrations are published in accordance with the "First Come First > Served" guidelines as described in [RFC8126]. They are to contain the > following information: > > 1. Subdomain name to be used in the category. The name MUST exist as a > direct subdomain for the domain referred by the proponent, and MUST > contain a non-empty _domainkey subdomain at the time or > registration. > > 2. Short description of the category, and criteria for assigning > messages > to this category, possibly containing a link to extended > description. > > 3. Trust that recipients are invited to assign to messages signed by > such > subdomain. This MUST be one of the key words "none", "low", > "medium" > and "high". > > 4. Date of the registration. > > Note: Domains are invited to re-use existing names rather than > registering > new ones, if the intent matches the description. These names are not > visible by users, so there is no reason to use IDNs. Names and > descriptions MUST be in English. I just want to say +1 to all of this. I believe that adding more d= signatures to convey context is the solution to allow ESPs/intermediaries to express enough information to allow receivers to make a mail handling decision in a way that minimizes collateral damage. Jesse___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Replay attack definition discussion
Presumably a last message of mine. Without any personal insult meant i wanted to complain on the the initial sentence Mailing-lists have long complicated email authentication. And this echoes IETF documents written a decade and longer ago (last week i looked on my local ones and i think as early as 2011). This is the stance ever since. And i always felt, and always said in public, that it is quite the opposite. It is not and has never been despite the repetitions that mailing-lists break email authentication, but quite the opposite, it is that the way that authentication was implemented broke mailing-lists, which struggle ever since. You are free to call that bullshit, but i call the above, given all the struggle that so many mailing-lists face for more than a decade, and increasing, insolent. Like i did. If the stance would change to something like saying that "operational needs required a timely solution for authentication that unfortunately degraded mailing-list operators" then that would surely sound better. Just to reiterate: the basic principle in use for email for so many years, "[alias-]forwarding" (and even i have two for only this account, CPAN and sourceforge, i am sure many active young people which work at so-and-so-many projects, and whatever, have much much more), as well as mailing-lists which tag subject lines, and insert (headers and) footers, were forcefully neglected for, in reflection, mysterious reasons, .. so i can tell *where* here the bullshit is, and who produced it. I would, if i could, strongly urge to place the burden on fixing DKIM onto DKIM, so that only DKIM has to be implemented and used everywhere (because, mind you, many do _nothing_ such, and only try to get out of the way of IETF outcome, by removing subject tags, footers, and whatever). You gain a cryptographically verifieable path from sender to receiver, and _finally_ mailing-list software is enabled to *do* anything to help authentication. Now i must admit that for copying out the above sentence, via browser, i saw the word "Prior" and that reminded me of something that Mr. Vesely said, and that, in turn, let me read some more sentences of that draft. Not more, i do not like ARC. I think the DKIM workout would work out (whatever other problems that would entail), possibly with the addition that whitespace in the base64 (encoding headers) shall be ignored so that lines can easily be broken (seems to be a deficit in the standard that artificial whitespace can be introduced, ie, RFC 5322); 'just realized that since the nmh MUA had M-L [sic] traffic on that issue (of overlong lines). (I do not need to see my name on that btw. My approach is better :)) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
