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

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

>  On 6/11/13 3:58 PM, Melvin Carvalho wrote:
>
>
>
>
> On 11 June 2013 21:50, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>>  On 11 Jun 2013, at 21:47, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>
>>
>>
>> On 11 June 2013 21:39, Henry Story <henry.story@bblfish.net> wrote:
>>
>>>
>>>  On 11 Jun 2013, at 21:28, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> 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 ... ?
>>>
>>>
>>>  And how do you stop a man in the middle changing all those pieces of
>>> info as you fetch them?
>>> What is the algorith you use for trusting those people? How do you tell
>>> them to update their
>>> system if your keys change? What do I do in case of clash? Etc....
>>> etc....
>>>
>>>  I don't think that quick answers to this point on a mailing list are
>>> going to be satisfactory.
>>> You need someone full time on these issues, and careful work with crypto
>>> specialists.
>>>
>>
>>  I think, as with much of security, there's no perfect answer to these
>> questions.  Tho for each scenario you can devise a strategy.
>>
>>  But the principle here is that the mirrored claims make things
>> incrementally better.  What's wrong with incrementalism?
>>
>>
>>  Well great. We're all waiting to see your implementation and the spec
>> that goes with it.
>>
>
>  Well it only works if people start doing it.  The algorithm is not too
> hard.
>
>  1. For each of your friend's keys, each with digest (d):
>
>  2. On your host add the document
>
>  /.well-known/di/d
>
>  Containing the triple
>
>  di:d
>    cert : identity
>      <webid> .
>
>
> We have to get around /.well-known/ due to its issues with letting users
> have full control, even when they don't control or possess admin privileges
> for a DNS server.
>
> You can handle this by adding a URL parameter to the di: scheme URI. Net
> effect, you can point to the location of the document associated with the
> digest denoted by the di: scheme URI.
>
> We do exactly what I just described in our X.509 cert generation services:
>
> 1. http://id.myopenlink.net/certgen
> 2. http://youid.openlinksw.com
>
> Example:
>
> 1. http://id.myopenlink.net/certgen/key/7959 -- public key URI
> 2. http://id.myopenlink.net/c/BVH477 -- page describing the cert
> associated with the public key
> 3. di:sha1;Ufn4rImd6QKET8LqDZwCkRaufLo?hashtag=webid&http=
> id.myopenlink.net -- di: scheme URI with the URL parameter
> 4.
> http://kingsley.idehen.net/about/html/di:sha1;Ufn4rImd6QKET8LqDZwCkRaufLo?hashtag=webid&http=id.myopenlink.net
> 5.
> http://kingsley.idehen.net/about/html/di:sha1;Ufn4rImd6QKET8LqDZwCkRaufLo?hashtag=webid&http=id.myopenlink.net-- back to the original public key description.
>

These links are awesome.  How did you generate the string:

sha1;Ufn4rImd6QKET8LqDZwCkRaufLo

Do we need to document this?


>
>
> Kingsley
>
>
>
>
>
>>
>>  Henry
>>
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>>  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/
>>>>
>>>>
>>>
>>>        Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
>>        Social Web Architect
>> http://bblfish.net/
>>
>>
>
>
> --
>
> 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
>
>
>
>