On Mon, Apr 28, 2025, at 15:37, Tero Kivinen wrote: > Bron Gondwana writes: > > DKIM2 provides an upgrade path where when the intermediate systems are > > upgraded to support DKIM2, every hop of the pathway is DKIM2 and you can > > eventually start requiring a full DKIM2 pathway to accept mail from more > > sites. I can anticipate a future DMARC-style technique for publishing a DNS > > record saying "do not accept messages from this domain that have exited the > > DKIM2 ecosystem at any point". > > You are saying these things like it would be good thing to build > walled garden, and enforce splitting email user base in two. > > The one problem I have DKIM2 is that it do require EVERY single email > server to be updated. This will be taking decades. It is the same > reason it was much faster to do IPv4 NATs (only update one > firewall/gateway etc) than to do IPv6 (you need to update every single > router). > > I am really scared on the day when big players start to say that they > do not accept email anymore unless it is DKIM2 signed, because then > email system has been split in two.
In the way that http and https web was split in two, yes. They may not outright ban it, but severely rate-limit it. > > There are going to be lots of devices like webcams, IoT devices etc > sending emails for alerts etc which suddenly can't send emails anymore > to DKIM2 users. They should either be sending over RFC6409 submission rather than port 25, or else coming from a trusted IP range to a mail relay which supports DKIM2 and puts its own n=1 signature on the message with a signed MAIL-FROM on its own domain. Big players are already severely rate limiting traffic from arbitrary home IP address ranges, because those IoT devices sending alerts are functionally indistinguishable from spam-bot-net members. > > With DKIM2, the second message would have on its copy from me: > > > > DKIM2-Signature: i=1; [email protected]; [email protected]; d= > > fastmailteam.com > > > > And then on its copies from the mailing list: > > > > DKIM2-Signature: i=2; [email protected]; [email protected]; > > d=ietf.org > > > > DKIM2-Signature: i=2; [email protected]; [email protected]; > > d=ietf.org > > > > DKIM2-Signature: i=2; [email protected]; > > [email protected]; d=ietf.org > > > > etc. Each with a separate signature, so they would be clearly not just a > > replay of a single message which was directed at the mailing list. > > So mailing list server will need to do around 300 signature > generations, the gmail needs to 2 * 61 signature validations (2 for > each recipient in their system, one for the original sender, and one > for the mailing server), and while doing that it needs to do undoing > the diffs for each copy of the email that came in (each of them has > different signatures, and changes might be different also as the > emails have been sent to different addresses etc, especially if there > is signed unique one click unsubscribe button in emails). It doesn't have to do the undoing unless it doesn't like the content of the message. And it likewise doesn't have to validate the original signature; it can trust that the IETF server has already done so ... again, unless it decides it doesn't like the message in which case the evidence is there to either exonerate or damn the IETF server. But yes, the mailing list server will have to do significantly more signature generation. It will only need to do the body hash calculation once unless it generates different body content per user. Sending email is a privilege, not a right. I'm OK with it costing a little more. This is still plenty less than some of the 'hashcash' ideas of the past, and CPUs are pretty fast. The receiving system - I don't know any systems which cache validation information across mutliple messages with the same signature. In most cases, mailing lists are already using VERP and sending each copy separately. If not, they probably should. We're just mandating existing best practice. > (and then some people complain extra work needed to do DNSSEC > validation, we are talking about order of magnitude bigger work load > here, and the difference is that DNSSEC validation work is shared > between the whole system, these calculations are not). We thought about this and considered it acceptable cost in 2025. Mailing lists will be most affected, but they create a lot email, and creating email is a responsibility! > This is quite a lot of more work compared to just checking one > signature for DKIM and one signature for ARC. Nope. You only have to check one. Which is the same as with ARC, where you had to check further signatures unless you blindly trusted the last hop to have correctly validated the previous hops. > > Even more importantly, they would have delta header fields: > > > > DKIM2-Delta-Header: i=2; > > > > b=Content-Type,bXVsdGlwYXJ0L2FsdGVybmF0aXZlOyBib3VuZGFyeT0iXy0tLS0tLS0tLS09XzE3MjkwMDgzODQzMTE0NjAi; > > t=Reply-To; > > t=Subject,Re: [Ietf-dkim] Re: Fwd: New Version > > Notification for draft-crocker-dkor-00.txt; > > t=To,[email protected] > > DKIM2-Delta-Body: i=2; > > c=126-5231 > > > > Which would allow the gmail server to tell, if it didn't like content of the > > message, whether the badness had been introduced by the IETF server, or was > > present in the original message from me. And it could validate the first > > DKIM2-Signature (i=1) to be sure that the bad content had come from > > Fastmail's > > server. > > I do not know how gmail will know whether the changes done by the IETF > list was done in bad actor manner or not even if it has the diff of > changes the IETF mailing list does. Neither do I. Yet somehow, people can feed a message into a "is this spammy" AI or regex or human, and get an answer. They could do this with the previous version as well, and see if the answer was similar. Sure this is an imperfect science. But I don't actually understand your objection here. You have the new message and way to reconstruct the old message, so you can see what's different and decide if you like that difference or not. > If IETF mailing starts adding footer to every single email going > through IETF list that explains the copyright and patent policy of > IETF lists, as that bad actor change or not? If the recipients don't like it, it's a bad change. > How about when it starts adding advertises for the next IETF meeting > in Madrid? If the recipients don't like it, it's a bad change. > And next it will start send hotel advertisements for the Madrid IETF, > then adding advertises for restaurants near hotel etc... If the recipients don't like it, it's a bad change. > When will this be considered to be bad? When the receipients don't like it. Also; there's an implied contract that the mailing list has when the user signs up to the list, and if the list breaks that contract the user will unsubscribe. Your strawman here is very un-interesting to me. What is interesting is knowing that the IETF list added that content, not the original sender; so Gmail (or whoever) can decide if the IETF servers are the source of content which their users don't like in aggregate, or if I (the original sender) am the source of content which their users don't like in aggregate. If 99% of the email that the IETF servers are generating is considered "unwanted" by Gmail's users, then its reputation is going into the toilet and its email isn't going to be reaching inboxes, regardless of whether it's just an update to remind them of the Notewell that the users all consider objectionable. > My guess is it depends on the recipient. Only recipient (the actual > user) can decide whether things changes done are over what he/she > expected. Yes, precisely. And in aggregate, that's the input signal that most email sites are using. There's no moral judgement of "good" or "bad" to particular content, it's a crowd-sourced reputation of whether users want it. And the better sites can distinguish where to attribute that reputation, the better they can filter content. To the extent that a dishonest actor can mislead the destination about the source of the content being delivered, the less valuable reputation tracking is. Both good reputation AND bad reputation. The value of a "DKIM Replay" attack, to a fair approximation, is in hijacking of reputation systems - which were built on DKIM (for good or ill). One of the largest values of DKIM2 (disclaimer about naming included by reference) is that it makes it much easier for reputation systems to distinguish said dishonesty. > > Yours brings some benefit, but the overall benefit is trivial > > > > So, making it easy to detect DKIM Repaly is a trivial benefit? Wow. > > > > If it detected DKIM Replay in the general case, it would not be trivial - > > however it only detects DKIM Replay in the direct case. It's still not > > possible to distinguish between an alumni forwarder and a DKIM replay; short > > of keeping a database of every alumni forwarder that points to you, and at > > scale that's decidedly non-trivial. > > Alumni forwarders etc are not set up by random people. For you to have > such forwarding means you actually are alumni of that place. So for > the final recipient of the email it is TRIVIAL to know what forwarders > he/she has that will forward email to his/her mailbox. Uh huh. I do actually somewhat buy this. And even the "it's trivial to know which mailing lists you are signed up to". But that information is only available at quite a distance and at scale that's a lot of manual fiddling. The SMTP server receiving an email and deciding whether to reject at SMTP time, or generate a delayed MDN later, or discard it - that's not the "final recipient" with their reliable recall of which addresses represent them. > So setting up for trusted ARC signers for the user is trivial for that > user, but impossible for anybody else. > > And note, that user might also have forwarding that he/she did not > request which he/she does not consider trusted, and whose ARC > signatures he/she does not want to be consider valid. > > Email forwardings does not happen randomly. The user sets up those > forwarders that he/she cares about. Adding that forwarder to the > trusted ARC signers list at the same time is easy task. > > And that is very scalable situation. I would assume most people have > only few (less than 5) alumni forwarding types of email forwardings. > > Mailing lists are different thing, I have no idea how many mailing > lists normal users are member of, but again they are something that > they know about themselfs, so when they join mailing list they can add > that as trusted ARC signer at the same time. > > The reason ARC has not been usable is that some people do think there > should be this "global trusted ARC signers list". This whole concept > of global list is wrong. I do not have any forwardings from > yahoo/hotmail/gmail etc to my final mailbox, so I do not trust ARC > signers of those domains, as they should not ever forward email to me. > For some other users things are different. What you are able to do as an individual with deep knowledge of the underlying tech is not scalable. Gmail, Yahoo, et al didn't do what you propose, and not because they're cretins who don't understand ARC. Or maybe they are cretins who don't understand ARC - I certainly am, But I understand regular users, and they sure aren't going to be manually adding a trusted ARC signer for every mailing list they sign up for. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
