At its core of this proposal, sites run their own CAs and users install site-specific client-side certificates. Many organizations have been doing this for years. For example, MIT: http://ist.mit.edu/certificates .
I like client certificates as an additional factor in general, but user enrollment across multiple devices, browser and platform compatibility, and revocation of lost devices are a pain. I think the biggest adoption of client certificates has been in large organizations with managed devices and support staff. Incidentally, there have been attacks to use client certificates as persistent "supercookies" to track users, but I don't know the current state of how browsers handle this. Here's an old PoC: http://0x90.eu/ff_tls_poc.html . Firefox 4 at least prompts you before dumping your cert to https://www.apache-ssl.org/cgi/cert-export . The author also makes claims this could prevent cross-site scripting with a "cryptographic same origin policy". I don't buy that, since XSS attacks could still be served from sites with valid certificates. If someone has a vulnerable web app, it's still going to be vulnerable. Finally, this proposal requires changes on server-side authentication and potentially in browsers themselves. Sites don't typically change their authentication system unless it drives user adoption (e.g. OpenID or Facebook Connect) or is needed for security (e.g. 2-factor auth). I don't see any incentives for adoption here. On Tue, Mar 12, 2013 at 4:31 PM, Kyle Maxwell <[email protected]> wrote: > I appreciate the intention, but I see a lot of problems here. Without > doing an exhaustive analysis: > > A. This doesn't eliminate phishing because users will still enter > their credentials at a site that doesn't actually match the one where > the cert was previously signed. Otherwise, existing HTTPS controls > would already protect them. > > B. What zone would contain user keys for DNSSEC? > > C. Your message transport protocol seems a little unclear - could you > walk through it? > > There are more issues here, but at a minimum I feel like it doesn't > adequately address a broad enough threat model. > > On Tue, Mar 12, 2013 at 4:08 PM, Guido Witmond <[email protected]> wrote: > > Ladies and Gentlemen, > > > > > > I've long disliked the direction the internet headed with regards to > > privacy. Or it's total disregard of it. > > > > I've come up with a novel architecture of existing old and recent > > cryptographic tools that offers a substantial improvement in security and > > privacy. I call it Eccentric Authentication. > > > > Unlike the current CA-system that requires people to trust them to gain > > security, my protocol turns that upside down. Security is what the > protocol > > provides. Trust is what people gain by using the system. > > > > The protocol is mostly compatible with the current internet as we know > it. > > And it prevents most phishing attacks for free. > > > > I have the hope that this protocol can shift the balance of security and > > privacy a bit back towards the people. > > > > I've written a technical description at [1]. I hope it makes things a bit > > clear. Feel free to comment. > > > > With regards. Guido Witmond. > > > > 1: http://witmond.nl/ecca/eccentric-authentication.html > > -- > > Too many emails? Unsubscribe, change to digest, or change password by > > emailing moderator at [email protected] or changing your settings at > > https://mailman.stanford.edu/mailman/listinfo/liberationtech > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at [email protected] or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at [email protected] or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
