Re: WebID security picture

> What use is it if some parts of the document are signed, but all the rest is something that could be changed by the "unreliable host"? That host after all could just not serve the profile at all. Or it could add lots of links to porno images, or just be constantly lying about you, or worse lie about you on a few occasions.

Because for WebID as a _login mechanism_, many applications don't need to care about the vast majority of the content of a FOAF document, only the parts relating to the key you've used...

> I think it is much simpler: if you don't trust the host, don't publish there. Don't give your WebID to people with a URL of a host you don't trust. It will be very bad for your reputation.

How does my grandmother decide which hosts she 'trusts'?

> If one looks ahead a bit, can one imagine a world of ipv-6 enabled, where your devices always have the same ip address? I am not sure how that works for mobile devices. Otherwise one could have dynamic dns. I Again the simple solution is to have a pretty stable host. Most people have a home, and that is a good place to put one. It is protected by very strong laws.

That's a huge leap. Technologically? sure, it can happen. but there's more to this than the technology: and you factor this into your arguments regarding teaching how to maintaining keys, etc…

>> By the same token, this has to be balanced by usefulness, surely? If there are lots of WebIDs out there but they have limited usefulness, then that's not necessarily a great result if you could have lots of WebIDs out there which are more useful by being a little more restrictive and making efforts to mitigate those restrictions?
> 
> You don't mean usefulness, you mean quality of data, right? And you mean that data quality will be bad because people will put their information on unreliable hosting servers? But those hosting servers have an identity and a reputation to watch out for also. 

No, I mean usefulness. As a relying party, if you need a two-way cryptographically-strong association between the certificate and the subject URI before you can use that subject URI as an identifier, then a system which doesn't provide that is less useful than one which is.

> This sounds to me very much like the critique that people would have put up against Tim Berners Lee when he started the web in the early 1990s: "Would it not be better to have data that is controlled by high quality institutions, regulated by law, than a free flowing web of pages that anyone can put up on unreliable hosts? That data will surely be so bad as to damage the reputation of the web. Would it not be better to make the protocol more complex by making sure that pages only point to resources that exist, and that those resoures point back...."

No, it's not at all like that. More like the arguments which brought about SSL/TLS, and later brought its more widespread use…

>> Here's a concrete example of why I'm concerned about this:
>> 
>> I use the EasyWebID Facebook application to generate the FOAF document for my WebID, because some of my friends did the same thing. It produces FOAF automatically based upon data it has access to in Facebook, along with a list of public keys I supply of WebID certificates.
> 
> Ok, though any such service will have to speak to the FB lawyers, and be very careful about what they do.

That's somewhat besides the point… such an application could exist without publishing any of Facebook's data—it was merely an example of something which it could do in order to help persuade people to use it and make WebID more easily-adopted.

>> I log into a bunch of sites using WebID certificates. These sites don't care deeply about the public keys that I use, because to do so would be annoying: as far as they're concerned, my user ID is http://apps.facebook.com/easywebid/nevali#person and I authenticate by providing a certificate with that URI in the SAN and checking that the FOAF document has a matching public key entry. If my login was my certificate's public key, then I'd only be able to log in from devices/browsers which included that particular certificate, which is both annoying and risky (I have to transfer pkcs#12 bundles about, increasing chances of compromising security on the private keys, and everything becomes reliant me not losing that key…).
> 
> yes. It is easier to deal with WebIDs. They can be linked to in documents most of all.

exactly, so we want 'the security of certificates, with the ease-of-use of the URI'?

>> Somebody later gains access to my Facebook account,
> 
> you mean the EasyWebID account

One gives access to the other; there is no separate EasyWebID account, it's just a Facebook application.

>> and adds their own certificate's public key to my FOAF document. Now, they can log in to everything I've used my WebID for previously, impersonating me.
> 
> Indeed. There is the same issue with Facebook connect, and that relies on a password currently, though they are introducing https now too. I only use https.

https solves some issues, sure. it makes it harder for some classes of attack on the user to occur, but doesn't have any effect on others.

and, as Dominique said, OpenID suffers from the same problem, too.

but, OpenID isn't very popular, whereas we'd hope WebID would do better...

>> One could say “well, the EasyWebID Facebook application should take steps to prevent this from happening”, but there's every chance they won't;
> 
> Do you think Facebook will watch by things like this happening without taking any steps, when their whole strategy depends on exactly what you are proposing?

You can't log into Facebook with a WebID. It's of little interest to them. They still control your data — it's essentially just used as an alternative auth mechanism to Facebook Connect in this scenario.

> Because of course if EasyWebID Facebook, is just 1 step away from being Facebook itself. So there is at least one very large provider that could adopt this, and of course many other little ones, say IBM, Oracle, Apple, and all the members of this consortium. And why would there be a problem with individuals getting a plug and play Freedom Box?

Because there isn't a very good reason that persuades people to go out and buy a Freedom box. What's it for? Why would a non-geek want one? What does it do that Facebook doesn't? 

>> we can't rely on users being able to differentiate between a provider who is good at security and one who isn't if we can't rely on users knowing how and why private keys work and how to protect them…
> 
> one user by himself can't, but groups of thousands of users can. This is how our society functions. It is built on trust and reputation. 

> You don't just get a WebID anonymously, you get it from meeting someone, or through friends, acquaintances, colleagues, etc... 

Sure, but this doesn't help if you don't know anyone who's got one yet...

>> So, lending more weight to the IDs of the key in the client certificate isn't an option because it massively reduces the utility of WebID as a proposition,
> 
> It massively reduces it compared to some ideal of security you are thinking about. But turn things around, and look at how far it brings us from where we are now with centralised social networks, unencrypted e-mail, servers with only http (and open to man in the middle at every level),....

right, I know that, my point is: the difference between that 'ideal' (which isn't ideal, but is "good enough") and the base proposition isn't very big.

>> and similarly increases chances of lost identity.
> 
> It increases it compared to some ideal of security you have and which you are comparing this against.
> 
> The real world is different. Recently my mother's GMail account was taken over. She had a bad password and could not understand the issue with security. Now she does. 

what about all the people who's gmail accounts haven't ever been taken over? they need to know too...

> To move to public key cryptography identity would already be such a big improvement that it will remove the biggest security holes that exist in the internet infrastructure now, while making life for people easier - no user name password to remember anymore. 
> 
>> But relying on the subject URI means that if somebody gains access to the place where the WebID is published, everything I've ever used WebID to log into is now accessible as well, so that's not viable either.
> 
> But of course you won't have only 1 webid. You could have many: your private freedombox one, your university, your company, your bank, the state (to fill in taxes). You can link them or not as you wish. Different instuations carry different weight, and they will have different security thresholds. They will guarantee different information too.

*You* won't have only one WebID... maybe others on the list similarly.

How do you encourage individuals to go to the trouble of creating different WebIDs and associating them with different services? even then, the problems outlined above still apply sufficiently to make it a problem: maybe the attacker adds their key to the WebID used at university, or your bank, but doesn't bother with the taxes one…

or should everyone have a certificate generated by each of these sites instead? (i.e., no SSO—I can't see why that would be useful, though; might as well take the FOAF out of the picture and just have SSL client certs in that situation).

M.

-- 
Mo McRoberts - Data Analyst - Digital Public Space,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
Room 7066, BBC Television Centre, London W12 7RJ,
0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A




http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Friday, 8 April 2011 14:04:32 UTC