Re: unlinkability

On 7 Oct 2012, at 23:14, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> On 7 October 2012 23:04, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 7 Oct 2012, at 22:57, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>> 
>> 
>> On 7 October 2012 22:21, Henry Story <henry.story@bblfish.net> wrote:
>> 
>> On 7 Oct 2012, at 21:16, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>> 
>>> 
>>> 
>>> On 6 October 2012 12:03, Henry Story <henry.story@bblfish.net> wrote:
>>> 
>>> On 6 Oct 2012, at 12:01, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>> 
>>>> 
>>>> 
>>>> On 6 October 2012 11:42, Henry Story <henry.story@bblfish.net> wrote:
>>>> 
>>>> On 6 Oct 2012, at 11:39, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 6 October 2012 11:25, Henry Story <henry.story@bblfish.net> wrote:
>>>>> >>
>>>>> >> (1) I think solves the unlinkability problem
>>>>> >
>>>>> > Can you explain what the unlinkeability problem is? Or for who it is a problem?
>>>>> >
>>>>> > 4.  Unlinkability
>>>>> >
>>>>> >    Definition:  Unlinkability of two or more Items Of Interest (e.g.,
>>>>> >       subjects, messages, actions, ...) from an attacker's perspective
>>>>> >       means that within a particular set of information, the attacker
>>>>> >       cannot distinguish whether these IOIs are related or not (with a
>>>>> >       high enough degree of probability to be useful).
>>>>> >
>>>>> > This is something Harry brought up.
>>>>> 
>>>>> Can you explain why it is problematic. It is not because he brought it up
>>>>> that it is problematic right? Or is he someone who sets the standards
>>>>> of what is or is not problematic? Through what authority?
>>>>> 
>>>>> Harry stressed that this was a key consideration to him.  As an influential member of the social web (he was chair of the W3C Social Web XG), I would consider his opinions important.  His complain was that he raised this before, and that the webid group did not look at it.
>>>> 
>>>> But you have not summarised in your own words what his complaint is. So how do you know we did not answer it?
>>>> 
>>>>> 
>>>>> If we, as a group, are able to address such concerns, or show that we have evaluated them and proven then are non issues (for example in a FAQ), it may help bring the benefits of WebID to a wider audience.
>>>> 
>>>> That is why I ask you to express in your words what the problem is, and see if you can come up with an answer to the 
>>>> problem. And indeed we should add this on a list of question and answers that comes up.
>>>> 
>>>> I have quoted the passage cited by Hannes, Harry and others. 
>>> 
>>> yes, but you have to develop that passage and see how it applies to WebID. It is not an obvious passage at all, and it is not clear it applies at all to WebID.
>>> 
>>>> It's something we (as a group) have been asked to look at.  In truth, it's been quite a hard conversation to follow as there were many replies and points raised in a short period of time.  I dont know if unlinking the public key from the URI provides more 'unlinkability', it was just a suggestion.
>>> 
>>>> 
>>>> But it seems unclear to me that the concerns have been addressed. 
>>> 
>>> Well I did in fact answer that mail. But I am going to send out a new mail right now, to make sure it is clear.
>>> 
>>>> Certainly there was no acknowledgement of that. 
>>> 
>>> By whome? By Harry? He never acknowledges mails that don't go in his direction.
>>> 
>>> OK, I've managed to look through a lot of this now.
>>> 
>>> Unlinkability seems to be useful when you want to provide anonymity or pseudo anonymity.
>> 
>> [[
>>       Unlinkability:  Within a particular set of information, a state in
>>       which an observer or attacker cannot distinguish whether two items
>>       of interest are related or not (with a high enough degree of
>>       probability to be useful to the observer or attacker).
>> ]]
>> 
>> Unlinkability is with respect to an attacker or observer.  So one has to ask who the attacker or observer is.
>> In the case of wikileaks, the attacker is the person who wishes to find out who posted the leak. They want to
>> correlate that person to something else presumably.
>> 
>> In the case of the social web, it is going to be quite complex who is an attacker. I think to be able to
>> specify this one would have to look at the access control on a resource. If I want to make a resource
>> available to a group of friends, then they cannot be the attacker.  The attacker would be someone
>> who is not my friend being able to look at the TLS traffic and work out who is connecting. It would be
>> interesting to see what TLS+Tor gives one there in terms of improvement.
>> 
>> If the web site you are connecting to is the attacker, then you want to minimise their ability to correlate
>> your buying decision for X with another buying decision for Y on another site.  There you'd just
>> create a local account on that site, and then use some form of e-payment. But you'd not want to give them any 
>> interesting info about you or else they'd soon be able to identify you - and there the e-payment system
>> is already problematic.
>> 
>> So what unlinkability means depends very strongly on who is thought to be attacking who.
>> 
>>> 
>>> Both valuable use cases.
>>> 
>>> I am guessing the perception of those that have never tried webid may be that the certificate is sent *every* time.
>> 
>> 
>>> 
>>> This can be avoided as follows:
>>> 
>>> - Do not send a cert when the popup arises
>> 
>> 
>> yes, usually there is cancel button on the cert selection box.
>> Or: don't click the login button.
>> 
>>> - Use a different browser
>> 
>> Or a different person in the same browser, as in Chrome's Profile options.
>> 
>>> - We create a public cert at http://webid.info/#anon
>> 
>> I am not sure that would be useful. Just don't log in. But perhaps for sites that require certificates?
>> 
>>> 
>>> Pseudo anonymous identifies can be provisioned by WebID
>> 
>> yes, pseudonyms
>> 
>>> 
>>> - One cert per identity
>> 
>> Not sure how that helps
>> 
>>> 
>>> Linkabiity is desirable in many cases as stated in the final paragraph of the IETF draft.
>> 
>> Well spotted, thanks:
>> 
>> [[
>>    Achieving anonymity, unlinkability, and undetectability may enable
>>    extreme data minimization.  Unfortunately, this would also prevent a
>>    certain class of useful two-way communication scenarios.  Therefore,
>>    for many applications, a certain amount of linkability and
>>    detectability is usually accepted while attempting to retain
>>    unlinkability between the data subject and his or her transactions.
>>    This is achieved through the use of appropriate kinds of pseudonymous
>>    identifiers.  These identifiers are then often used to refer to
>>    established state or are used for access control purposes, see
>>    [I-D.iab-identifier-comparison].
>> ]]
>> 
>>> 
>>> BrowserID aka persona seems not to solve this issue as the cert sends:
>>> 
>>> - The user's email address.
>>> - The user's public key for that address on that browser.
>>> - The time that the certificate was issued.
>>> - The time that the certificate expires.
>>> - The IdP's domain name.
>> 
>> 
>>> 
>>> Additionally your webmail provider and/or mozilla can impersonate you as they control your private key server side.
>> 
>> 
>> My guess is that with web crypto in the browser that will go. But until then perhaps.
>> But I am  not quite sure it is that: I think that they control the signature. And the signature 
>> means they can make a private key at will. 
>> 
>> That is the same problem with WebID btw.  But it's not a problem if you have a FBox webid, because then you control it.
>> The server serving the page is a key agent in this system. It is the @ sign of the e-mail address
>> 
>>  - FBox: henry.story@henry.story ( you control your box)
>>  - Uni:    henry.story@ic.ac.uk       ( you are part of a bigger agency )
>> 
>> Each has its advantages.
>> 
>> Anyway even with Web Crypto in the browser the only advantage BrowserId has is that the certificates 
>> are changed a lot so you can verify the cert just by checking the signature. (If you don't care to have 1 day error ) 
>> But the value of WebID for social web is of course all the other relations you can access. And of course 
>> they will want those too. 
>> 
>> So that is why my point was from the beginning to Harry: you can't defend BrowserID and slam WebID 
>> simultaneously. It's inconsistent.
>> 
>> Harry's only point is that your profile server might be able to track where you go, and even that is only very 
>> weakly true. And its hardly interesting in most cases anyway, since it is your own profile server that may possibly
>> be able to know. I think you can find out who is behind this if you ask "who would this be problematic for?"
>> Certainly not for people with FBoxes.
>> 
>>> By extension any agency that requests information from your webmail provider or mozilla can view your external data.
>>> 
>>> Furthermore, your webmail provider and/or mozilla can sign you up for any services offered by a relying party *without you even knowing*. 
>> 
>> Why is that?
>> 
>> If the private key is stored on your webmail provider or mozilla they can create a certificate to impersonate you.  This means they can view your account or even create an account on the relying party.  Say you had some confidential documents on a service, it means your webmail provider can read not only your mail, but your external documents.
> 
> They can create a certificate to impesonate your - your e-mail that is - anyway, even without your private key. BrowserId Relying parties only consider the signature of the certificate for verifying it. So the private key is neither here nor there.
> 
> Sure there's actually TWO private keys in play.  The 'master' key which is used to sign and your temporary key in the browser.
> 
> It's possible to impersonate with WebID if they take over your identity page. 

Who is they? Above you speak of your "webmail provider", which for BrowserId is the equivalent of WebID's profile server. Your WebMail provider is the authority of your e-mail, your profile server is the authority of your http WebID. Your profile server can add a new key to your web page, and the e-mail provider can add a new certificate and use it too, since it can sign it.

> But the key would change which is suspicious.  Even SSH warns you when a key changes and alerts you to a possible attack.

The key changing is suspicious in ssh command line, because it does not use a CA mechanism, and so there is no other way of verifying the public key of a server. If one used WebID or DNSSec that could go away completely.

But changing keys, may or may not be suspicious. I doubt BrowserID make the changing of keys a factor of suspicion anywhere. 

They rely entirely on the signature of the e-mail provider.  That is ok, because the e-mail provider is the authority for e-mails. One could of course have the e-mail provider sign a token proving that an e-mail is in foaf:mbox relation with a webid. If so then looking up that in the webid profile could constitute proof that an e-mail belonged to a webid. 



>  
> 
>>  
>> 
>>> This is quite scary in privacy terms and has me thinking twice whether I want to use BrowserID as a fallback to WebID, as was my original intention.  Perhaps let the user decide.
>> 
>> yes, but I am not sure quite what the FAQ would be here other than 
>> "What is the distinction between WebID and BrowserID?" 
>> http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
>> 
>> But I am not sure what the question would be that Harry is asking, other than FUD
>> 
>>> 
>>> Maybe we should add these points to an FAQ
>> 
>> We should certainly link to that article in the FAQ, and also perhaps move the FAQ to our wiki,
>> or at least move the FAQ to the w3c WebID/FAQ from the foaf+ssl/FAQ
>> 
>> But yes getting back to Linkability, the answer has to be 
>> 
>>    - 1. The importance of linkability (see my previous mail)
>>   -  2 Who is your enemy?
>>      then one could make a table, and for each on suggest an answer
>>        the site you re logging into: don't use webid
>>        Otherwise I am not really sure what one can say here yet that is that interesting - ie not something that ends
>>        up falling down to TLS level issues which might be fixed with other systems such as Tor.
>> 
>> Perhaps an FAQ is important enough to go on webid.info? 
> 
> Well it can be anywhere, as it can be linked from there. We can do more with WebID.info at some later point...
> But we don't have that much manpower at present.
> 
>>  
>> 
>>>  
>>> 
>>>> Perhaps it is the nature of mailing lists that it can be challenging to know when a consensus is reached or a problem  has been solved.
>>>>  
>>>> 
>>>> Henry
>>>> 
>>>> 
>>>>>  
>>>>> 
>>>>> Henry
>>>>> 
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>>> 
>>> 
>>> Social Web Architect
>>> http://bblfish.net/
>>> 
>>> 
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/