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

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

>  On 6/11/13 1:53 PM, Melvin Carvalho wrote:
>
>
>
>
> 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.
>
>
> 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.
>

Yes that's one way to revoke.


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

Yes, or MITM.  I didnt say it was likely, but some folks view it as an
important attack surface.


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

Yes, but you need servers to replicate the data, to add robustness.  Think
distributed databases.


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

Perhaps but it's at least been stated that the profile document is
vulnerable to MITM.


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

This is the theory.  But in practice we have single points of failure
today.  But replicating data we can get from A to B.  Also note how HR14
comes in to play as you separate the document from the content cleanly...


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