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

On 6/11/13 1:53 PM, Melvin Carvalho wrote:
>
>
>
> On 11 June 2013 19:00, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto: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.

Which one? I can just delete the relation in my profile document which 
renders the private useless. For instance, let's say the device hosting 
my private key was physically stolen, all I need to do is log into the 
server hosting my profile en route to deleting the relation that 
associates my WebID with the Public Key that pairs with the private key 
on my stolen device.


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

My profile document and acls aren't the same thing. You have to access 
my profile document, control the computing device hosing my private key, 
grok RDF semantics, and a few other steps. All of this within a 
shrinking time-frame with forensics friendly digital fingerprints being 
generated all the time.

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

Yes, they you have to coordinate all of this knowledge and 
infrastructure control en route to a futile assault.

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

It's baked in. We just need more actual apps that actually comply with 
Linked Data principles.

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

There will be many rules. The basic rule is the starting point. There 
has to be a starting point for folks to understand the basic concept.

> For casual interactions use your cache or the HTTP profile.  For 
> something more important you can cast a wider net.

You can de-reference across the web inside a processing cycle in a 
program. I do it every other hour of the day. The network is my computer :-)

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

I don't agree.

Folks need to implement something first. Let's have implementations 
instead of stalling that effort on the basis of possibilities. There is 
beauty awaiting all of our beholders (dressed up as doubters, at this 
point).

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

There is not single point of failure since logic is transcendent. We 
don't have a single relation. We just have a critical relation that 
offers a launchpad for wonderment :)

Kingsley
>
>
>     -- 
>
>     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/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile: https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>


-- 

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