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

[Tom Herbert <[e-mail]>]

On Fri, Mar 30, 2018 at 4:35 PM, Fernando Gont <[e-mail]> wrote:
> 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
>
Right, single use addresses are the one case that could reasonably
claim to provide any quantifiable level of privacy.

>
>
>>  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".
>
Maybe, but then this pushes the impetus to the applications to
understand the ramifications on privacy when presented with choices.

>
>
>> 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?
>
Well, for instance, in security the strength of crytosystem can be
measured but the computational effort needed to break keys. I wish
there were equivalent metrics for privacy. We aren't going to find
something like that here, but we should be able to define what
quantifiable strong privacy in addressing would be (section 5 of
draft-herbert-ipv6-prefix-address-privacy-00). As pointed out in that
draft, NAT can meet those criteria for strong privacy so that might at
least provide a baseline for comparison.

>
>
>> 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.
>
Right, so we're just left with providing unquantified "soft" guidance
to users for which privacy might be a critical concern.

>
>
>> 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.
>
Yes, that is why we need identifier/locator split. Other than a
provider prefix, addresses wouldn't contain any topological
information.

> 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).
>
Right, the privacy problem needs to be addressed in the network.
RFC4941 acknowledged this, but somehow addresses created per that RFC
came to be known as "privacy addresses".

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

It would be interesting to see a proposed API.

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

I'm not convinced of that given recent revelations for some major
applications concerning privacy and addressing.

Tom

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