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. 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. > 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). (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). This is quite a lot of more work compared to just checking one signature for DKIM and one signature for ARC. > 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. 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? How about when it starts adding advertises for the next IETF meeting in Madrid? And next it will start send hotel advertisements for the Madrid IETF, then adding advertises for restaurants near hotel etc... When will this be considered to be bad? 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. > 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. 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. -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
