On Mon, Feb 5, 2018 at 9:22 PM, Lorenzo Colitti <[email protected]> wrote:
> On Tue, Feb 6, 2018 at 2:17 PM, Tom Herbert <[email protected]> wrote: > >> Section 8.3 provides the argument that singleton addresses are needed for >> privacy-sensitive communications. For practicality and probably scaling /64 >> is needed, however for strong privacy singleton addresses would be needed >> (to avoid resorting to NAT). >> > > You don't need singletons for privacy. You can just assign /64s that > change over time. > Yes, that seems to be the recommendation of RFC4914. However, neither that RFC nor anyone else that I can tell has been able to quantitatively describe the relationship between frequency of changing prefix and privacy. Any statements about this are qualitative in nature. By intuition, it might be believable that higher frequency should mean better privacy, but nobody can quantify that. So for a user where privacy is paramount, my example is a political dissident that is anonymously criticizing their government, there is no definitive answer to give then when they ask what frequency they need to ensure their privacy. Besides that, I believe that any frequency could be defeated with the postulated exploit below (if you see a flaw in this logic please let me know). Actually, there is one frequency where the privacy effects can be qualified: that is to use a different address per connection. This is effectively what stateful NAT provides and why law enforcement doesn't like it. With a large enough pool of users behind a NAT, flows sourced form the same device cannot be correlated by a third party in external network. This is strong privacy privacy in addressing (properties listed in 8.3). In lieu of telling the political dissident to find a provider using NAT, assigning addresses for singe use can provide it. Assigning a /64 to every flow won't scale, but singleton addresses could. ---- The following exploit is proposed to defeat the privacy goal of periodic address rotation: - The attacker creates an “always connected” app that provides some seemingly benign service and users download the app. - The app includes some sort of persistent identity. For instance, this could be a login to account. - The backend server for the app logs the user identity and IP address they are using each time they connect. - When an address change happens, existing connections on the user device are disconnected. The app will receive a notification and immediately attempt to reconnect using the new source address. - The backend server will see the new connection and log the new IP address as being used by the user. - Thus, the server has a real-time record of users and the IP address they are using. - The attacker gains access to packet traces taken at some point in the Internet. The addresses in the captured packets can be time correlated with the server database to deduce the identity of the source of packets for flows communications unrelated to the app. Tom
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
