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

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?


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