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

On 11 June 2013 19:00, Kingsley Idehen <kidehen@openlinksw.com> wrote:

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

If someone gets access to your key, you need to revoke it.


> 2. Public Profile Document access
>

This is the point of failure.  If someone can access your profile, they can
modify the key, and grant themselves a new cert.


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

3-5 you can read about in the spec (1 day)


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


Yes


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


It may exist in theory, but we dont really do it, to my knowledge.


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


I'm not suggesting only one rule.  I'm suggesting a safety net to make the
existing rule stronger.  For casual interactions use your cache or the HTTP
profile.  For something more important you can cast a wider net.


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


You only need a few, you could just drop in a RWW script in that directory
and watch it grow.


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


Agreed.  But right now there is, and that is deterring some from using
WebID.


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


Ahhh but the beauty is that these are ABSOLUTE URLs due to the hash.  The
document is not opaque and contains the hash, which can link the key to the
user, over many many servers.  Pick your favourite(s).


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

But our WOT have singular relations, the principle here is to replicate to
distribute trust from a single failure point, to many data points ...


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