Financial Cryptography

There is still the chance to game people via the use of plain old non https. If you really look at it the human engineering issue is people rarely look at their URL bar and will and do place information that should remain private for security reason in forms. In fact the stored information on the Micronoodle browser will probably assist them in this effort. So now what all the efforts towards a solution do not address the human engineering issue wjat is next. Next automatic browsers that do not allow the user to place information stored as secure in non https guis. Then only approved sites for online commerce where the user needs to define who has their information? The herding of the cattle of commerce is winnowing the users into box cars for shipment to Microsoft. So now that Micronoodle has created a security regime of the monopoly variety the consumer is still liable for the insecure enviroment and pays the bill. DRM and phishing are linked in that the restriction of property for security purposes removes legally and physically the rights to property that the consumer has purchased. Since it is the consumers money that is being stolen and their rights that are being taken they must be able to make choices. My fear is the small crack of a situation will generate a monopoly for Micronoodle one that cannot be undone. Consumers now go to jail for sharing their property online and will eventually loose the right to their private information as well. In the end no liability for phishing will be assigned to any software manufacturer. Its the stupid cattle of commerce the online consumers fault. Micronoodle loves the beef and knows where its done. Conflicting opinions on standards might require different roads and a divergence. At this point a stampede from anything Micronoodle is in order.

Just to clarify: The Toronto meeting and all other discussions I personally have had with Microsoft, Opera, and KDE (i.e., George Staikos) have been primarily related to PKI and CA issues, with anti-phishing in general discussed only in passing. I'm at a loss to figure out what your reference to "the penny drops" is about.

Also, note that as best I understand it, Microsoft's plan is to put the CA name in the chrome only for cases where a (so far hypothetical) "extended validation" certificate is used; for other certificates (meaning: every cert in use today) they plan to retain the current UI, which doesn't show the CA name. (Admittedly their blog post isn't clear about this, so I may be wrong in my recollection.)

Frank, thanks for the clarification. As no doubt you understand, we only get to read about this in the press or on blogs so all sorts of misinterpretations are likely. I don't know what the CA / PKI agenda is unless it is that idea to create a "better" class of verification.

For my own interests, I'd like to clarify that I'm primarily interested in user security, and only vaguely interested in PKI and CAs. Mostly they are interesting as a sort of institutional and crypto architecture hobby related to payment systems work. See my writings on the link, especially the 'harmful' one.

User security starts at "threat modelling," which is a fancy way of asking what users are being raided on. As we speak, the threats to users are trojans/spy/malware, phishing, viruses and spam, in approximately that order. For phishing, there is a well documented way in which PKI and CAs can help deal with the attack - use the existing cert as a bootstrap to relationship management by the user. Then PKI and CAs suddenly become important to user security and we really want PKI to start taking it seriously. We saw some good movement in your blog entries, but more needs to be done, and those of us who are interested in user security will continue to ride the case on PKI until that is done.

Frank, the problem with responding to your comment is the distance between user security and PKI / CAs. What is PKI / CAs for if not user security? Isn't phishing the biggest challenge ever to CAs and PKI? If it can't be used to stop phishing, what the hell is it there for?

Surreal!

On the other issue: if Microsoft is only going to do the CA name if it is super-validated, you are correct. That's blown it right there. Bummer.

What if the URL coloration is defeatable? Then couldn't that system backfire. Isn't it safer to say "Maximum threat at all times. Use your intellegence to determine if this is phishing. Give out information sparingly always."

More clarifications: I didn't mean to imply that CAs and PKIs had nothing to do with phishing; in fact, our discussions of CAs and PKIs were in the context of phishing. My point was simply that our discussions in Toronto were not meant as some sort of grand anti-phishing summit covering everything that browsers could possibly do to address phishing, we were simply discussing the CA/PKI aspect of it. (I don't mean to imply that discussing other anti-phishing measures isn't important, it just wasn't on the agenda in this particular meeting.)

Regarding the "CA/PKI agenda", the main idea that is being discussed is indeed that of having some sort of "extended validation" certificates for which CAs would do vetting of certificate applications in a manner that was demonstrably more rigorous than is typically done today, is relatively standardized across CAs, and is independently audited. Again, I don't think that this is in and of itself a solution to phishing, but in the context of CAs and PKI I think it could be worthwhile.

Finally, I realize that things that may be obvious to me may not be obvious to others; as you point out, you're getting limited information, and getting it secondhand. That's why I've tried to respond to comments on my blog and here on yours, so I can address specific questions and provide clarifications where warranted. My only caveat is that I can speak only for myself and the Mozilla Foundation, not necessarily for the Mozilla project as a whole nor for the individual development teams for Firefox et al.

Frank, I apologise for getting narked. Sometimes when a ray of sunshine slips through, I think the clouds have gone away. But any real sensible analysis indicates that this is just a beginning in security for browsers.

I understand your caveat - and repeat my calls for a Security Director for Mozilla. Unfortunately nobody speaks for security at Mozilla, something that I know will not be agreed within but the evidence of absence is compelling.

The issue is that Firefox is heading towards a non-trivial percentage of the market. At around 10%, it needs a non-trivial approach to security, and at the moment, Mozilla has basically the same as any other application - an all care but no responsibility approach. When Firefox was first started, the world state was that browsing was a relatively safe environment, and the lessons of the 90s applied, but by the time Firefox started to grab market share all that had changed.

I'm not sure that it's necessary to go for the full security goal that I've pushed for; consider that as a context setting goal. Such is really quite a draconian goal, and it holds back the BSD and the PGPs from penetration. But something in that direction would be strategically very sensible for Mozilla, which is becoming more exposed with every percentage point of growth.

> What if the URL coloration is defeatable?

Then it is broken :) But that is a bug and can be dealt with as a bug.

> Then couldn't that system backfire. Isn't it safer to say "Maximum threat at all times. Use your intellegence to determine if this is phishing. Give out information sparingly always."

No, not really - this assumes someone who walks in a war zone. For the most part, most ordinary users in most ordinary places will not be under attack; if you tell them they are likely to be attacked at any moment and they have to take on a maximum threat posture they will - quite rightly - assume you are a kook and ignore you :)

We have to stop pretending we can secure all the people all the time. We cannot; but what we can do is create systems that close off the most likely holes. Phishing is the "the most likely hole" by dint of it being a widely used attack against browsering. We won't ever get rid of it, but we can reduce its efficacy by using tricks like the user's own knowledge.