[liberationtech] Announcing a privacy preserving authentication protocol

[Guido Witmond]

On 03/13/2013 08:33 AM, Petter Ericson wrote:

> 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).

Indeed, correct. The local CA root certificate is the *identity* of the 
site. The browser restricts accounts to the site.


>>> 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).

That's how I foresee it now. It could be a DNS(SEC)-based directory. I'm 
not sure which way to go with that. Perhaps your WoT could help here.

> 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.

It does fit in badly. I foresee the messaging part to be used both for 
person-to-person messages like email but also to bootstrap other secure 
connections. For example, a dating site that lets people connect over 
ZRTP. The message could just contains the endpoints and keys for that 
session. See: [2].

XMPP might be a better fit.

> 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

It would reduce the risk of pressure on the registrars to block a site.

The requirement for a replacement of DNSSEC/DANE needs a secure 1:1 
mapping of human-readable name to FPCA-Root-certificate.


With Regards, Guido Witmond.

2: 
http://witmond.nl/blog/2012/10/22/the-worlds-most-private-dating-site.html 
  (warning: old text)