Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Announcing a privacy preserving authentication protocol

Petter Ericson pettter at acc.umu.se
Wed Mar 13 00:33:18 PDT 2013


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 <kylem at 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 <guido at 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 companys at 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 companys at 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 companys at stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech

-- 
Petter Ericson (pettter at acc.umu.se)



More information about the liberationtech mailing list