In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin wrote:
The problem space is that most folks won't catch the difference between an email and link from ripe.net, ripe.org and ripe.ca. The game is lost long before a purely technical version of validating the message source becomes an issue.
You're reply is along the lines of what several other folks have told me privately, and I think they all miss the mark of where I am going with my suggestion. Hypothetically, I get an e-mail from ripe.ca, which uses some trick (perhaps as simple as HTML text and link that go to different places) to visually show me ripe.net and actually sends me to ripe.org. Let's also assume I have a ripe.net account and have been to that web site before. The software can do a pile of things that make life better for the user: 1) When I reach ripe.org (from the phish above), my browser can say: "This is an SSL web site asking for a login and password, and yet, you've never been here before. Maybe you would prefer to register, or leave if you came here incorrectly." That's all client side UI, and would make even novice users stop and think about what happened. 2) Let's say the e-mail was signed, by ripe.ca, the original sender. When my e-mail client passes the URL to my browser, it can also pass the details of the ripe.ca key. My browser can then say "You got an e-mail from Key ABC, but went to a web site run by XYZ, are you sure this is what you want to do?" Of course if everything matches, it can be silent. Specifically I am NOT suggesting to ever trust a root-CA, or the details in a certificate. Indeed, browsers could ship with no certificates what so ever in my scheme. The key is comparing multiple sources of information. Most folks might not know the difference between ripe.ca and ripe.net. The existing CA scheme may allow both of them to get the common name "Réseaux IP Européens", confusing even the technical who look close. But it's trivial for the software to say Cert in E-mail != Cert in Web, or even that they don't have a common branch in the tree (in a large org they may have the same parent, for instance). As I've also said, a good UI feature would be the ability to add a description to a cert locally. Once I'm sure my banks web site is legit I should be able to add "Leo's Bank" in the cert store locally. Now when my web browser or e-mail client use that cert to validate a message they can display "Leo's Bank" next to it. I can easily look for that and know I went back to the same place. I click on a link in my e-mail and see no description, I know something went wrong. Does my scheme stop all phishing. Heck no. If we wait for a perfect solution we'll never have any solution. Look at NANOG. Bandy Rush is here somewhere. It's why many years ago I set my mailer to PGP all e-mail to NANOG. See an e-mail from me not signed, don't trust it. Does that stop all impersonation on NANOG. Heck no, but if we all did it, and subscribed to the web of trust, it would all but stop it. Users hate encryption and ignore the warnings not because they don't want to be secure, or are idiots. They do it because the darn software is broken, confusing, and has the worst UI's ever invented. If the industry fixes it, encryption will be much more widespread. Small steps, like banks allowing users to upload an cert to their account profile, and then communicate via two-way authenticated e-mail would go a long way to traning the user community how this should work. End user ISP's (cable, DSL) issuing e-mail certs automatically and installing them as part of their install package would be a quantum leap forward. It's not hard, people just don't do it. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/