Re: unlinkability

On 7 October 2012 23:27, Henry Story <henry.story@bblfish.net> wrote:

>
> 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 <http://tools.ietf.org/html/draft-iab-privacy-terminology-01#ref-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.
>

They = the entity that highjacks your webid profile.

Your webmail provider is your authority only if they have credentials in
.well-known/browserid ... otherwise it's mozilla.


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

Agreed.  But as I mentioned before I do track webid keys over time.  It's
one extra service linked data offers.


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

Agree in principle, but it's not a 100% like for like comparison.  It's
much harder to move your mail account than it is to host a static page.  So
there's an element of lock in.


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