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

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




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