Well, given that protocol uses essentially now new tech (apart from the message bit, which to me looks a bit superfluous), it should require relatively little time to implement properly.
Furthermore, there are various parts of the protocol that are Good Ideas, independently of the other parts - having a per-site CA, with trust anchored in the DNSSEC hierarchy is _significantly_ better than the current CA system, imo.[1] Kyle: > > 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. Not speaking for the protocol author, but afaict, the client cert is tied to the specific domain, meaning if you enter the wrong domain, you won't get a "similar" page where you enter your credentials - you'll get a page where you're not authenticated (the client cert is never sent to a different domain from where it was signed). > > B. What zone would contain user keys for DNSSEC? I am not entirely sure what you are referring to here, but the server provides the (signed) user public keys to any who asks, no DNSSEC necessary. I am guessing a common API should be used for this (www.server.com/get-pubkey?uid=<user> or somesuch). This does let the server MITM messages unless you have sidechannel pubkey verification, which is another reason why I find the message storage bit to be somewhat badly integrated. I agree that the most cumbersome thing would seem to be supporting multiple user devices, or, indepentently, multiple users on the same browser session (log out me, log in my SO without killing the rest of the browser session). These are significant hurdles to overcome in order to gain adoption, but not insurmountable, I think. Once FPCAs are served via the DNSSEC hierarchy instead of having predefined CAs (if this ever happens), I think moving to client certs might very well be adopted as a "user convenience" thing. We'll see what happens though, but I'm at least somewhat hopeful. [1] though of course, a distributed/decentralised WoT-like construction for the complete DNS hierarchy may be preferrable overall On 12 March, 2013 - Steve Weis wrote: > 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 <ky...@xwell.org> 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 <gu...@witmond.nl> 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 compa...@stanford.edu 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 compa...@stanford.edu 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 compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Petter Ericson (pett...@acc.umu.se) -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
