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

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.

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/