Tuesday’s panel session titled “What Is Special About My Application?” at the IDtrust2009 symposium was interesting, and went well. Its goal was to explore key security/privacy/identity issues in some online applications, looking at the significant challenges and what might be needed in research and standardization. Five panelists gave brief introductory presentations, which we followed with some Q&A/panel discussion.
The applications were these:
- Health care (Walter G. Suarez, Institute for HIPAA/HIT Education and Research)
- Electronic voting (Andrew Regenscheid, NIST)
- Social networks (Barry Leiba, Internet Messaging Technology)
- Putting government online (Bob Sunday, Government of Canada)
- Cloud computing (Stephen Whitlock, Boeing)
There were some good questions about ownership of data and services in computing clouds, about privacy in social networks, and about health-care and voting issues. Not surprisingly, there are security and privacy concerns that are unique to each application, in addition to those common to all.
One interesting observation came from the session’s moderator, Tim Polk of NIST: that legal issues come up in most of these, leaving us with questions of how the law will work with the technology to protect users’ interests.
On Wednesday we had a good session about browser security. Anil Saldhana of Red Hat talked about recent changes in browser security features, as well as about an upcoming W3C security recommendation for browsers. David Chadwick of the University of Kent previewed a paper that will be in a conference next month, showing how well browsers conform to the X.509 specification as to how they handle validation of certificates.
The bottom line of Professor Chadwick’s tables is that most browsers warn and query the user when they encounter server certificates that look suspicious to them. Asking the user what to do is bad: most users are unqualified to answer the question, and, because what the user wants to do is visit the web site, the only answer most users will give is "accept the suspicious certificate."
The session spurred an interesting discussion, going from authentication mechanisms to social engineering by “bad guy” web sites (spoofing the padlock symbol, for instance). I said that browsers should never ask users to approve security exceptions, and that we have to set up recommendations that move us toward refusal to allow web sites to use faulty certificates. Someone noted that “extended validation certificates” (EV Certs), which now result in a green area next to the address bar, are really what all certificates should have been from the beginning, and that existing (non-EV) certs are largely useless.
Slides from all the panelists and from the other sessions are available on the symposium program page
1 comment:
Nice post - thanks.
But re this comment:
Someone noted that “extended validation certificates” (EV Certs), which now result in a green area next to the address bar, are really what all certificates should have been from the beginning, and that existing (non-EV) certs are largely useless.Certificates have always been a problematic way to address many use cases. Moving to far more expensive EV certificates is probably appropriate for certain brand-name sites, but for the fast majority of sites that have more need of encryption than brand-name recognition, it seems to me that a combination of dnssec and TLS via self-signed certificates would be the appropriate long-term solution. When will browsers have access to the dnssec status and be able to communicate that to the users?
Someone in the audience brought up the wifi captive-portal authentication use case, when the user has a password from the portal which the portal doesn't want observers to be able to sniff. But the portal is often providing a free service and certainly doesn't see uch value in buying a pricey cert. I'm hoping there are better wifi authn approaches for that situation, but don't know the details.
Post a Comment