Re: mitigating Webid (+ TLS') single point of failure

On 11 June 2013 20:20, Henry Story <henry.story@bblfish.net> wrote:

> Melvin, you forget that you could also use .onion or .garlic urls if you
> really don't want to rely on DNS.
>
> As for the rest I think it is interesting. But it seems like a lot of
> work, which will require
> working on a logic of trust, and much more. Perhaps a Phd thesis?
>

You really think it's that much work?  OK, then how about this:  we each
take the keys of people in our friends list, and cache the reverse lookup
for them ... ?


>
>
> On 11 Jun 2013, at 18:30, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
> The WebID + TLS flow has one single point of failure, and that is that you
> have to trust the profile page.  If the profile page is somehow
> compromised, or the victim of a MITM attack your whole authentication
> process could be compromised.
>
> Now some people say you can add trust by adding an SSL certificate, or in
> the future, perhaps DNSSEC.  However, this can be unsatisfactory, because
> A) it's costly, B) you are just shifting the single point of failure
> around.  Other projects have pushed back against using WebID for this
> reason.
>
> A more effective technique might be to distribute trust across the whole
> web.
>
> When the TLS handshake takes part, the sever can be mathematically sure,
> that the public key it receives is authentic.
>
> The *standard* flow is to add a forward follow-your-nose lookup from the
> certificate to your profile page.  But what if we, as a community, were to
> distribute the trust across many many servers, using the read write web.
>
> Instead of a FORWARD (follow your nose) lookup, you can do a REVERSE
> lookup on the public key, using the di: (digest) URI scheme.  A neat
> feature of the di: spec is that it also has a /.well-known/di directory
> where you can put digests and and get back a document.
>
> It may be fairly simple to set up a single directory that allows users to
> go in and update their info on your server.   You may even charge a small
> fee for it.
>
> In this way a server does not have to rely on a single point of failure as
> the relationship between a key and a user will be distributed in many
> places.  In this way you can perform extra checks as required to verify the
> authenticity of a login, as needed...
>
>
>
> Social Web Architect
> http://bblfish.net/
>
>