Bron Gondwana writes: > Yes, at the end local policy on the receiver trumps everything else, but I > think we're over-optimising for the security gateway at recipient end at the > expense of the sender intent here. Paypal-et-al really REALLY need a way to > indicate that particular parts of their message MUST NOT be modified for the > message to be in any way similar to what they sent. If we hand wave this, > we're going to create ourselves a pretty solid attack vector.
We clearly have evidence that paypal-et-al do not care about that. If they would really need this they would use S/MIME or PGP and sign all their messages. As they are not doing that, they are cleary not REALLY needing that. If you are thinking about malicious changes, like someone changing the amount to be paid or similar, then EVERY single email would require protection against malicious changes. On the other hand someone adding text at the end of the mail saying "this email is from outside source" etc, should not matter for even for those companies. So what kind of changes you think those companies do want to avoid, and what is the difference compared to other emails, that requires them to have this extra level of "protection"? > HAVING SAID THAT - DKIM2 still provides a ton of protection because you can't > just replay a message that you got a copy of, because you can't sign as a > domain on its path. But the threat model is still something like this. > > Service "X" is used to generate invoices. Bad actor "B" gets "X" to generate > an invoice to "B". They then rewrite the message, providing a recipe and all, > and forward it to victim "V". "V" gets a message which is a legitimate > invoice from "X" with modifications along the way. If their systems say > "Invoice from X, dkim2=pass, fully valid" then this a totally compliant DKIM2 > chain. Give "B" a compelling sounding lookalike domain, you've got yourself a > social engineering friendly DKIM2 abuse vector. Have all invoices from "X" > say donotmodify , you close this vector. I think this is inherit issue in DKIM2. DKIM2 assumes that user will check the modifications done to the message and verifies that they are acceptable for him. This does not apply to just invoices, it includes all messages where you want to have DKIM2 "protection". Donotmodify is just expressing one such policy, i.e., no changes at all (even in headers, i.e., no from address rewriting), but this is just one special case. I could also take this email after it has gone through DKIM2 enabled IETF mailing list servers and send you a copy signed by IETF mailing list services but modified by me (with DKIM2 recipies) to say different things to you than what I others in the list will see. Any malicious change is bad for any email there is not only one class of emails that would benefit from this. Of course if your DKIM2 enabled mail user agent is smart enough it could show you all emails in "track changes" mode, which would show you all changes that happened to the email, and then you would immediately notice that B has changed the invoice, or that the mailing list message was modified after going through the mailing list server. -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
