Re: I-D Action: draft-fgont-6man-rfc4941bis-01.txt

[Fernando Gont <[e-mail]>]

On 03/29/2018 05:59 PM, Tom Herbert wrote:
> Hi Fernando,
> 
> I may be missing it, but I don't see in the draft where it directly
> answers the question: "How often (literally what frequency) must IPv6
> addresses be changed to ensure privacy?".

There's no answer for such question.  Network activity can be correlated
as long as you  reuse the same address. So, if you want no correlation
at all (to the extent of RFC4941), then you'd never reuse an IPv6
address. Again see
https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations-04



>  And if there are
> applications that don't tolerate address change across connections,
> then what are the exact requirements for dealing rectify the frequency
> of change they can tolerate with the frequency needed for privacy?

As noted in draft-gont-6man-address-usage-recommendations-04, we need
appropriate APIs to fully leverage IPv6 addressing. At the very least,
for apps to be able to specify desired addressing properties such as
"stability".



> The common problem with nearly any discussion on privacy and
> addressing is that the effects of proposed guidance are seemingly
> never quantified. Statements like "The longer an address is employed
> (i.e., the more stable it is), the longer such correlation will be
> possible." are intuitively true, but they're not quantifiable
> statements from which we can elicit any actionable guidance.

What kind of quantification would you expect?



> For
> instance, it's reasonable to assume that an address that is persistent
> for 12 hrs. is less of privacy risk than one persistent for 24 hrs.

"It depends" (of course). What else is the system doing? Simultaneously?
etc.



> But _how_much_better_ is this privacy benefit to the user? Is the
> probability that a users privacy being compromised with a 12 hr.
> address 50% of the probability of a 24 hr. address? Probably not!

That depends on so many factors (apps being employed, activities taing
place, etc., etc., etc.) which, IMO, if you expect to get any sort of
"quantifier", it will be meaningless.



> Another problem with much of the guidance is that recommendations may
> only be useful for a given point of time. For instance, RFC4941
> recommends the default address change to be one hour. Even if that
> provided good guidance ten years ago, it is almost certainly not
> reasonable today.

rfc4941bis is essentially an improvement of RFC4941bis (addressing known
issues that are within the scope of RFC4941, and incorporate errata).
What you want can't be addressed in rfc4941bis.

draft-gont-6man-address-usage-recommendations-04 tries to elaborate on
the problem statement.



> The capabilities of attackers and data collection
> has increased substantially so that they don't need nearly that much
> time to do their work. In fact, we proposed a simple exploit in
> draft-herbert-ipv6-prefix-address-privacy which would defeat any
> frequency of address change to provide privacy except when a different
> address is used per connection.

I'll take a look at your I-D.



>> RFC4941 just contains some default settings when your system is flying
>> blind, because it has not idea of the requirements of the app employing
>> the addresses.
>>
> Please look draft-herbert-ipv6-prefix-address-privacy. This deals with
> the privacy implications off address particular the problems of of
> assigning persistent prefixes to host devices (just changing IIDs is
> not sufficient for privacy).

I'll certainly take a look.

That said: topologically-dependent information will certainly identify
the node.

There's nothing you can do in terms of privacy when your upper node
controls how you get your addresses (whether that's because you are
leased addresses with DHCPV6, or whether because you are given a unique
prefix).



> Side note: I think your statements about APIs being so rigid that we
> couldn't make necessary changes to ensure user privacy might be overly
> pessimistic.

I'm not saying they are rigid. THey are just *extremely basic* for the
addressing capabilities of IPv6.


>  APIs are not written in stone and we can change them over
> time. Also, there's a lot that can be done even without API changes.
> For instance, if we are able to give the stack a pool of one-use
> addresses, it would be particularly difficult to change address
> binding for client communications to select from that pool. This
> wouldn't effect applications that do explicit address binding, and for
> the SMPT, POP3 these could opt-out (maybe by an environment variable).

Doing that is just guesswork on other side (a different rehash of the
guesswork in rfc4941). We should let app specify their requirements
regarding IPv6 addressing. *They* know better.

Thanks,

-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1