Re: Address privacy

[Fernando Gont <[e-mail]>]

On 28/1/20 17:57, Tom Herbert wrote:
> 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. 

The timer definition is pretty specific, on the other hand.


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

The answer is obviously: the more you reuse an address, the more you 
allow the window/ability of correlation. Only the app knows the specific 
needs.

Temporary addresses are a middle-ground: even the app being unaware 
about the underlying mechanisms, you get some mitigation. Obviously, 
temporary addresses are time-bound as opposed to flow-bound, since that 
leads to fewer addresses in use, at the expense of allowing some 
correlation.

RFC4941 is a "default" mechanism that improves things a bit. If we were 
also to stress that they shouldn't be used for receiving connections, 
and hint OSes that they are free to drop e.g. incoming SYNs on them, 
then you get a lot more of value.

And yes, if you want to improve things even better, you need an API for 
the addressing capabilities. Shame on us that have produced so many 
different address properties without a way for apps to properly leverage 
them.



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

Please flag the text.

(One thing that did change is people's awareness... not necessarily the 
capabilities)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492