Re: Address privacy

[Tom Herbert <[e-mail]>]

On Tue, Jan 28, 2020 at 12:38 PM Mark Smith <[e-mail]> wrote:
>
>
>
> On Wed, 29 Jan 2020, 08:51 Tom Herbert, <[e-mail]> wrote:
>>
>>
>>
>> On Mon, Jan 27, 2020, 7:57 PM Fernando Gont <[e-mail]> wrote:
>>>
>>> On 28/1/20 00:10, Tom Herbert wrote:
>>> > On Mon, Jan 27, 2020 at 5:36 PM Fernando Gont <[e-mail]> wrote:
>>> >>
>>> >> On 26/1/20 18:37, Nick Hilliard wrote:
>>> >>> Tom Herbert wrote on 26/01/2020 20:16:
>>> >>>> It's intuitive
>>> >>>> that a higher frequency of address rotation yields more privacy
>>> >>>
>>> >>> intuitive, but probably inaccurate because of the a priori assumption
>>> >>> that privacy is strongly associated with the endpoint identifier.
>>> >>
>>> >> In many cases, it is: you log in to fb with a given address, and reuse
>>> >> that address to do other stuf
>>> >>
>>> > Yes, that's the "always on" network application that would allow
>>> > address tracking and identification at even high frequency of address
>>> > change. An exploit based on that is described in section 4.4 of
>>> > draft-herbert-ipv6-prefix-address-privacy-00. I believe the only way
>>> > to defeat this exploit would be single use (per flow), uncorrelated
>>> > address.
>>>
>>> Agreed. That said, temporary addresses, for obvious reasons mitigates
>>> activity correlation over time -- certainly not to the same extent that
>>> the paranoid "one address per flow" would.
>>
>>
>> Fernando,
>>
>> The rationale for temporary addresses may be obvious, but I don't believe anyone has yet quantified the effects. For instance, RFC4941 is thirteen years old, is there any evidence that it has materially improved anyone's privacy? (I'm not being cynical, but I think it's a fair question).
>
>
> It depends. What were the privacy goals RFC3041/4241 designed to achieve and does it achieve them?
>
> It isn't reasonable to come up with a different set of privacy goals that RFC3041/4241 weren't designed to satisfy and then declare 3041/4241 is a privacy failure because it doesn't satisfy them.
>
> Privacy isn't binary, there are different privacy threats and different parties to be private from. That means needing different privacy mechanisms to suit the different privacy threat models.
>
Ole,

I think the privacy goals of RFC4941 are clearly articulated as
addressing the problem of correlations that can be made on
identifiers. From the draft:

"
Anytime a fixed identifier is used in multiple contexts, it becomes
possible to correlate seemingly unrelated activity using this
identifier.

   The correlation can be performed by

   o  An attacker who is in the path between the node in question and
      the peer(s) to which it is communicating, and who can view the
      IPv6 addresses present in the datagrams.

   o  An attacker who can access the communication logs of the peers
      with which the node has communicated.
"

I think this should read "Anytime an identifier is used in multiple
contexts", that is drop the "fixed".

The proposed solution is temporary addresses. But then the question
quickly becomes how temporary do those addresses need to be to address
the problem of correlations? The draft only says "Temporary addresses
are used for a short period of time (typically hours to days) and are
subsequently deprecated.". That's pretty vague. For instance, suppose
a specifically user asks "How often do I need to change addresses to
ensure my privacy?".  Section 3.5 tries to address the question, but,
again is non-committal and makes no normative recommendation. I'd also
note that the text in RFC4941 is pretty much unchanged from RFC4941,
however the sophistication and data collection capabilities of would
be attackers surely have changed since 2013 so it seems like this
section should be revisited in light of that.

Tom



>
>>
>> One might compare this to the policy of some sys admins that users need to change passwords regularly. The rationale is similar, but that practice has been most debunked as not improving security and in fact is more of a burden to users that providing any real value.
>>
>> Tom
>>
>>
>>>
>>> Thanks,
>>> --
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: [e-mail]
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>
>>>
>>>
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------