Re: [foaf-protocols] Standardising the foaf+ssl protocol to launch the Social Web

=On 12 Jul 2010, at 00:04, Bruno Harbulot wrote:

> Hi Henry,
> 
> On 11/07/2010 23:47, Henry Story wrote:
>> 
>> On 10 Jul 2010, at 18:34, Harry Halpin wrote:
>> 
>>>> Great discussion folks!
>>>> 
>>>> I think this thread should give the w3 folks we are CCing here a good idea
>>>> of the passion, quality of work, depth of discussion and breadth of the foaf+ssl
>>>> community, which includes hackers from every programming language, researchers
>>>> from every continent, security as well as linked data specialists, and more.
>>>> 
>>>> Perhaps we should leave them a bit of time to digest the details of this thread,
>>>> so they can then let us know how we should proceed.
>>>> 
>>> 
>>> Digesting. Overall, great to follow, +1 to Bruno's points re security.
>> 
>> You mean the one where he suggests that the WebId protocol is not more secure
>> than OpenId? Why do you think this is true? I think it is clearly wrong, in
>> fact obviously wrong for a number of reasons of which the simplest is
>> just the relative complexity of the two protocols.
> 
> I think you've missed my point. The complexity of the protocol isn't really at stake here.

Well if you make a general statement, without specifying exactly in what way you think it is less or only equally secure, then the complexity of the protocol is
an issue. You can't ignore that.

Now I did not really want to go into details about this on this thread. But Harry seems to have forced the issue.... So excusing myself to the heads of the W3C in advance for the technicalities.

> Regarding security, what matters is the weakest link in the chain: it's the same for OpenID and FOAF+SSL/WebID (without building a cryptographic web of trust).

We have to be clear what the server knows at the end of the WebID authentication. At that point it knows just that the agent at the end of the SSL connection is identified by that WebID, that that WebID refers to that entity.

The Web of Trust then plays a role afterwards for issues of determining how much you trust what that agent says about himself. One element of that web of trust could be
that you are related in some way to a bank, that is itself listed in the government banking list. Which is pretty much how we get to trust banks now. 

> In both cases, whoever controls the hosting of the WebID controls the way the physical user may be challenged to prove their identity.

Not sure what you mean by "the way the user may be challenged". That service controls the WebId document. The service that controls the challenge is the relying party the user is logging into. It requests the client certificate.

> 
> For more important services such as banking, I don't want anyone who's not me or my bank to be able to impersonate me, or effectively change my password (or public key in our case). I don't want to have to wonder whether my hosting company is sufficiently honest or offers sufficient protections against hacking on their server for this sort of services.

That is not a problem. Your bank could issue a WebId too with its certificate, and in fact it could make sure during the SSL connection that the browser only sent a cert issued by it. 

> 
> It's a matter of risk assessment. If someone was to tamper with your CV on your website, you'd be upset, but you would certainly manage to limit the damage. If someone tampered with your FOAF document and if your bank allowed connections into your account simply on the basis of what the document dereferenced from your WebID contained, you'd be more worried.

This is just an issue of who you trust for what. I may trust your bank about whether you will pay me a certain sum, but not about your real business motives, your girlfriends, your music taste, etc.... I certainly would not trust your bank about any musical taste to be honest, even less than I trust them about money, given all the amazing things that happened this last year in the banking industry.

People in the security business have tended to treat banks as divine creatures. I think we can drop that now. They are human, all too human.

> 
> OpenID and WebID, by making the URL and its dereferencing as the primary pillar of trust, is fine for a large number of use-cases (most social networking frameworks, blogs, ...), but when the legal and financial consequences have higher stakes, you'd want a higher level of assurance.

But when you want to meet a girlfriend, your future wife, then I'd trust your social network more than your bank. 

> As it stands, WebID by simple dereferencing, without a cryptographic web of trust offers the very same level of assurance as OpenID.

No, it is much more secure.
 - no spelling mistakes by the end user as he types his id
 - less complex protocol (less errors therefore on that level possible)
 - forces HTTPS, which is well documented.

> Building a network of reputation (which is what you call "web of trust") by linking WebIDs as friends of other WebIDs is pointless if you can't make sure that the physical person gaining access WebID is indeed who they are. That's something that a (cryptographic) web of trust (a la PGP) can help with (I'm not saying it's perfect).

PGP is also less secure than foaf+ssl. For one it is a lot more difficult to retract a mistake in PGP, plus PGP leaks information: you can never undo a friend. See the FAQ:

http://esw.w3.org/Foaf%2Bssl/FAQ#How_does_this_improve_over_X.509_or_GPG_Certificates.3F

> 
> The real security enhancement of FOAF+SSL should come from the fact we have the cryptographic instruments (the keys) and that we *could* go further than effectively just checking who controls the hosting of a WebID. There is the potential, but this isn't something we do yet.

Well we do: if you use foaf, you could use the foaf friend network to establish a certain level of trust.

> 
> 
> In addition, you seem to assume that certificates reduce the complexity. Sure, there are fewer steps in the protocol, but there's also a security issue in how users perceive and make use of the technology. Unfortunately, most people consider that client certificate increase the complexity.

Because they look at books on the issue which tell them that this is the case. And indeed until you consider foaf+ssl, client certificates do seem to create problems.
But those problems dissapear with foaf+Ssl.

> As such, if they're badly understood, client certificates could be badly taken care of by their users, which could in fact make things worse.

Ok, so now the argument is one of the psychology of how people may misinterpret the security of the protocol. Well that's going to be something that will require a bit of practical education. People learnt how to do that for online shopping. Companies will need to work on developing simple games that help make this easy to understand.

Henry


> 
> Best wishes,
> 
> Bruno.
> 
>

Received on Sunday, 11 July 2010 23:31:20 UTC