Re: [dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign
On Saturday, April 25, 2015 5:34 PM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: Yes, the user did it to himself, but what does he know? Obviously too little to be trusted with an email account. Fire the corporate training department! Not an option. And sorry but it is not affordable to employ security experts in everyday clerical tasks. So the affected user remains on the payroll, and the company takes the hit in lost productivity because of email being inherently insecure, and because the security experts cannot agree to make it secure after 30 years of Internet email been invented. I also doubt it would work as well on Mac OS X, where the user would be prompted for his password to confirm permission to execute an application received from an untrusted source. I am not so sure, but I cannot test it right now in OS X. From an untrusted source came the ZIP file, but the EXE inside it is --when opened from the ZIP-- temporarily extracted to a $TEMP folder in the user's profile and run from there, so I guess the operating system has no way of knowing whether that EXE running form the user's $TEMP folder came from the untrusted Internet or not. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Saturday, April 25, 2015 4:29 PM [GMT+1=CET], Stephen J. Turnbull wrote: J. Gomez writes: What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? Isn't it obvious that Mediators bear all of the burden that *both* ends do? Of course, we perform both roles on each message. We verify signatures and filter messages on the way in, which potentially could reduce costs system-wide due to the multiplier effect of mailing lists (except of course nobody trusts us to do it well). We sign the version of the message that we send out. (These are functions of the MTA, of course, and we can't do a better or worse job than any Originator or Recipient. Except that to some extent Mediators may have information about the Originator that Recipient systems don't, which may improve filtering.) What else do you propose that we do? Well, if you ask... Mediators could take ownership of the Header-From whenever their involvement results in the Originator's DKIM signature being invalidated. Or some other change to their entrenched traditional behavior, like stop adding subject tags and body footers and being content with using some List-ID header to identify themselves, etc. Everyone (Originators and Receivers) is changing their email usage patterns/processes in order to take email to the next level (in reality, just to keep it a viable communication option in an increasingly hostile Internet environment), but Mediators seem totally unwilling to change their email usage patterns/processes. Email is changing. We all have to change to accomodate the fact that email is changing. Mediators don't seem willing to change at all. What I see is that email is about to evolve to the next level, and Mediators are at risk of being left behind if they refuse to change to accomodate the fact that email is changing. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 04/25/2015 11:50 AM, J. Gomez wrote: On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote: I will probably regret this, but since people are throwing around things like Pareto to argue in favor or against specific solution areas, I thought it might be useful to take a step back and look at what might make a solution (or set of solutions) useful to pursue. For indirect mail flows like mailing lists, there are three actors involved: 1. Originator 2. Mediator 3. Receiver For the purposes of this discussion I'll further categorize the entities involved as big and small (yes, it's way more complex than that, but I think that's sufficient). That leads to six combinations: Originator/Big, Originator/Small, Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. There have been solutions proposed that only require changes for one of the three above, that require changes at two of the above, and that require changes at all three. Nice framework. I'd like to note that it is the presence/existance of actor Mediator which induces the DMARC compatibility problems with indirect flows. I.e., if you supress the Mediator, all is fine and dandy. That fact should at leat put some pressure on Mediator regarding the searching for a solution, and should induce Mediator to acknowledge that he will have to assume certain costs for such a solution. I see Originator already assuming costs: deploying SPF in DNS and keeping it current, deploying DKIM records and DKIM-signing outgoing email, deploying DMARC records and being vigilant regarding Header-From alignment in his outgoing email, etc. And I see Receiver already assuming costs: setting up systems to check SPF, DKIM and DMARC for incoming email, dealing with the support costs of false positives and phised users, sending out DMARC reports, etc. What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? and what benefits do they get in return? /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
J. Gomez writes: What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? Isn't it obvious that Mediators bear all of the burden that *both* ends do? Of course, we perform both roles on each message. We verify signatures and filter messages on the way in, which potentially could reduce costs system-wide due to the multiplier effect of mailing lists (except of course nobody trusts us to do it well). We sign the version of the message that we send out. (These are functions of the MTA, of course, and we can't do a better or worse job than any Originator or Recipient. Except that to some extent Mediators may have information about the Originator that Recipient systems don't, which may improve filtering.) What else do you propose that we do? GNU Mailman has been working (desultorily) on lists which authenticate posters via personal digital signatures, but that isn't going to help much. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On 4/25/2015 6:32 AM, J. Gomez wrote: I.e., if you supress the Mediator, all is fine and dandy. ... and what benefits do they get in return? The benefit to Mediators is that they will avoid becoming an obsolete artifact of the past, like open SMTP relays. The word that is needed here is 'Procrustean'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis
On Saturday, April 25, 2015 12:24 PM [GMT+1=CET], Rolf E. Sonneveld wrote: On 04/25/2015 11:50 AM, J. Gomez wrote: On Thursday, April 16, 2015 4:11 PM [GMT+1=CET], Scott Kitterman wrote: I will probably regret this, but since people are throwing around things like Pareto to argue in favor or against specific solution areas, I thought it might be useful to take a step back and look at what might make a solution (or set of solutions) useful to pursue. For indirect mail flows like mailing lists, there are three actors involved: 1. Originator 2. Mediator 3. Receiver For the purposes of this discussion I'll further categorize the entities involved as big and small (yes, it's way more complex than that, but I think that's sufficient). That leads to six combinations: Originator/Big, Originator/Small, Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. There have been solutions proposed that only require changes for one of the three above, that require changes at two of the above, and that require changes at all three. Nice framework. I'd like to note that it is the presence/existance of actor Mediator which induces the DMARC compatibility problems with indirect flows. I.e., if you supress the Mediator, all is fine and dandy. That fact should at leat put some pressure on Mediator regarding the searching for a solution, and should induce Mediator to acknowledge that he will have to assume certain costs for such a solution. I see Originator already assuming costs: deploying SPF in DNS and keeping it current, deploying DKIM records and DKIM-signing outgoing email, deploying DMARC records and being vigilant regarding Header-From alignment in his outgoing email, etc. And I see Receiver already assuming costs: setting up systems to check SPF, DKIM and DMARC for incoming email, dealing with the support costs of false positives and phised users, sending out DMARC reports, etc. What costs are Mediators currently taking to improve validation/authentication of the email system as a whole? and what benefits do they get in return? The benefit to Mediators is that they will avoid becoming an obsolete artifact of the past, like open SMTP relays. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] MUA presentation - lessons from the Cryptolocker email-distributed virus campaign
J. Gomez writes: Yes, the user did it to himself, but what does he know? Obviously too little to be trusted with an email account. Fire the corporate training department! Please note this attack works successfully even if the user has no administrative rights on his computer, and could potentially be made to work equally well with Linux and MacOSX users too (if they were a big enough demographic target to make it profitable vs cost of development). AFAICS the cost of porting is very low compared to original development. I would guess that the real issue is that they don't have a good way to identify the executable format for the recipient system, and so send a payload that will work on well over 90% of recipients. I also doubt it would work as well on Mac OS X, where the user would be prompted for his password to confirm permission to execute an application received from an untrusted source. Surely some would type the password, but I suspect enough would be deterred to lower the click rate to unprofitable levels. The lessons which I think we can learn from this are: ISTM we already knew the lessons you list, and they inform every discussion I've seen on this list. My personal opinion is that, on the contrary, people are already way too quick to discard proposals simply because they involve changes to MUAs. Of course, the reality that this is an IETF WG, and what we can do that has effect with high probability is change wire protocols. MUA presentation is outside of our bailiwick, and nobody really has a good way to get ideas for MUAs broadly implemented the way we can influence MTA implementations. So I thought this could be of interest to keep in mind, when some solution may be suggested to the DMARC indirect flows problems which advocates some kind of MUA behavior regarding message presentation. No Silver Bullet. There are no solutions to these problems, only improvements. The fact that *some* users will dig a phish out of the spam bucket and cut/paste a disabled URL into their browsers so that they can be victimized despite the best efforts of their mail agents doesn't mean that others who *would* click if it were presented as valid mail would *not* go to such lengths for mail in their spam folders, or perhaps would be deterred at the cut/paste stage. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
