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

On 6/11/13 12:30 PM, Melvin Carvalho 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.

Hmm.

WebID + TLS doesn't have a single point of failure. Here's why, it 
leverages logic expressed in the profile document. The logic isn't 
fixed, and even if it was, you have to deal with the following:

1. Private Key access
2. Public Profile Document access
3. Understanding how RDF semantics are expressed
4. Understand how to construct an X.509 certificate with a WebID in its SAN
5. Understand Linked Data indirection.

There is only one vulnerability I know, and that's owl:sameAs inference 
implemented on the verifier side without any understanding of the 
semantics of that relation. Ideally, for such claims to be in the mix 
said claims have to be signed. Otherwise, owl:sameAs should at least be 
discouraged for basic implementations i.e., if you implement owl:sameAs 
then also have the appropriate protection in place.
>
> 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.

Keypair relation is verified.

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

It there already by way of Linked Data de-reference and caching etc..

> Instead of a FORWARD (follow your nose) lookup, you can do a REVERSE 
> lookup on the public key, using the di: (digest) URI scheme.

That's just another rule. We are not going to have a WOT based on one 
rule. The WOT is going to have to be about rules between parties i.e., 
each club has its membership verification rules that build on the basic 
rule.

> 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.
Yes, but "/.well-known" always introduces the issue of end-users not 
owning domains or having access to DNS.

>
> It may be fairly simple to set up a single directory that allows users 
> to go in and update their info on your server.

There shouldn't be a "single" anything in a truly distributed WOT.

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

But look back a few sentences, you have a single directory. You have di: 
and /.well-known/di etc.. these are single points of control and failure 
too.

>   In this way you can perform extra checks as required to verify the 
> authenticity of a login, as needed...
>
>
Just rely on the logic expressed in relations and our WOT will be super 
webby and super distributed and super smart :-)

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen