Search Mailing List Archives
[liberationtech] Announcing a privacy preserving authentication protocol
guido at witmond.nl
Wed Mar 13 04:59:04 PDT 2013
On 03/13/2013 08:33 AM, Petter Ericson wrote:
>>> 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: .
XMPP might be a better fit.
> We'll see what happens though, but I'm at least somewhat hopeful.
>  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.
(warning: old text)
More information about the liberationtech