Hey Ted,
yes, I should have been more precise.
Here is the current definition of "unlinkable sessions":
Definition: The term "unlinkable session" refers the ability of the
system to render a set of actions by a subject unlinkable from one
another over a sequence of protocol runs (sessions).
This definition talks about the "system" and it should rather talk about
eavesdroppers instead.
Better wording may also be needed since I just created it when I updated the
most recent draft version and I couldn't really find something else that worked
nicely.
You also raised the question what term to use when we actually want to provide
unlinkability towards one or multiple communication recipients. This is
essentially the debate about "profiling" and we could use terms from there.
Here is what I have in the document:
Definition: We use the term "profiling" to mean learning information
about a particular subject while that subject remains anonymous to
the attacker. For example, if an attacker concludes that a
subject plays a specific computer game, reads specific news
article on a website, and uploads certain videos, then the
subjects activities have been profiled, even if the attacker is
unable to identify that specific subject.
Ciao
Hannes
On Feb 13, 2012, at 6:35 PM, Ted Hardie wrote:
> 2012/2/13 Hannes Tschofenig <[email protected]>:
>>
>> I believe we need terms for three cases:
>>
>> 1) Hiding of your identity towards the final communication receiver.
>> 2) Hiding of your identity towards eavesdroppers (along the path between the
>> sender and the receiver)
>> 3) Avoiding the relationship between two (or more) protocol runs
>>
>
> So, I think it is useful to distinguish among the cases you have
> above, but I think the third
> needs a bit more work. Avoid disclosing the relationship between two
> or more protocol runs
> *to whom*? There's a difference between providing the protocol
> mechanics to make two sessions
> unlinkable to the outside observer and to making them unlinkable to
> one of the parties to the session.
>
> regards,
>
> Ted
>
>> My suggestion for terms is:
>>
>> ad 1) Anonymity & pseudonymity (as currently defined in the draft)
>> ad 2) Identity confidentiality (currently not in the draft)
>> ad 3) unlinkable session (as currently defined in the draft).
>>
>> I could add examples for each of these cases from IETF protocols to the
>> draft to draw the relationship with currently developed IETF protocols.
>>
>> Does this make sense to you?
>>
>> Ciao
>> Hannes
>>
>>
>> On Feb 10, 2012, at 3:44 AM, [email protected] wrote:
>>
>>>
>>> Hannes Tschofenig <[email protected]> 写于 2012-02-09 16:53:01:
>>>
>>>
>>>> Anyway, I believe that anonymity isn't the right term for that
>>>> document when the privacy threat is focused on the HIP responder
>>>> getting to know the host identities. The HIP responder receives the
>>>> HITs in the exchange.
>>>>
>>>> The only form of protection the document seems to provide is the
>>>> usage of pseudonyms. A HI itself is already a pseudonym (based on
>>>> the definition of a pseudonym in the document) and the main question
>>>> here is about linkability and about the lifetime of these
>>>> pseudonyms. We could, for example, regularly re-compute a new HI and
>>>> use it. This may be computationally more expensive but would provide
>>>> some level of protection. The problem only shows up in relationship
>>>> to other usages of the HI, for example, for access control. In the
>>>> draft this blinded HIT is used that is essentially derived from the
>>>> original HiT (and consequently from the HI). An attacker may not
>>>> able to learn the original HIT (or HI) but may still be able to make
>>>> the individual protocol runs linkable to each other. Note that this
>>>> mechanism has often been provided by other protocols as well (see
>>>> all the network access authentication protocols).
>>>
>>> I think unlinkability is stronger than anonymity( " An attacker might get
>>> to know
>>> information on linkability of various messages while not necessarily
>>> reducing anonymity of the particular subject. ")
>>> so anonymity is the basic requirement for privacy protection?
>>>
>>>>
>>>> Btw, where did you got this anonymity definition from that you cite
>>>> below? I don't think it is particularly good. Imagine that you have
>>>> a VoIP service offering that only has two users, you and me. If an
>>>> adversary eavesdrops on the communication it may not find out
>>>> whether it is you or me (without using further information) but
>>>> that's a pretty bad privacy protection. Instead, it would be much
>>>> better if the anonymity set is much larger.
>>>
>>> I got the definition of anonymity in P10 [in Foundations of Group
>>> Signatures: The Case of Dynamic Groups
>>> http://www-cse.ucsd.edu/~mihir/papers/dgs.html]
>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> PS: It may turn out to be useful to add another term to the document
>>>> to express the common property of hiding the identity of the
>>>> initiator to eavesdroppers, such as "initiator identity confidentiality".
>>>
>>> or as a special case of anonymity?
>>>
>>
>> _______________________________________________
>> ietf-privacy mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ietf-privacy
_______________________________________________
ietf-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-privacy
