- From: Christine Runnegar <runnegar@isoc.org>
- Date: Wed, 19 Aug 2015 06:42:26 +0000
- To: David Singer <singer@apple.com>
- CC: 🔓Dan Wing <dwing@cisco.com>, Mike O'Neill <michael.oneill@baycloud.com>, Nicholas Doty <npdoty@w3.org>, Eric Rescorla <ekr@rtfm.com>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>, Jan-Ivar Bruaroey <jib@mozilla.com>
> On 18 Aug 2015, at 6:27 pm, David Singer <singer@apple.com> wrote: > > >> On Aug 18, 2015, at 4:02 , 🔓Dan Wing <dwing@cisco.com> wrote: >> >> >> On 18-Aug-2015 05:16 am, Mike O'Neill <michael.oneill@baycloud.com> wrote: >>> That’s why IPv6 had autoconfig privacy extensions, so the local IP addtress is based on a random number (i.e. not the MAC address) + the network prefix. >> >> Major OSs only change the privacy address every 24 hours (iOS, OS X, Windows). Is that sufficient to avoid tracking, compared with the relatively-permanent local NATted address (which due to how DHCP clients and servers work, will often re-assign the exact same IP address, so long as it is available in the pool). >> > > I have wondered whether we need a new DHCP method “give me a DIFFERENT address, please!” as, as you say, DHCP servers usually try to give you the same address as it previously gave to this MAC address. But, I think the IETF is not enthused about rev’ing IPv4, and indeed most users get to hide their true IPv4 address as they are behind a NAT anyway. > > The IPv6 privacy address cycling could, of course, be different. One concern is over networks where the network prefix effectively identifies a single host (I think this is the case in cellular, for example); fiddling with the device part may be immaterial if the attacker can work out “that prefix is one assigned by a cellular network, and therefore the prefix identifies a single host”. Christian Huitema is doing some very interesting work on anonymity profiles for DHCP clients in the IETF https://datatracker.ietf.org/doc/draft-huitema-dhc-anonymity-profile/ > > > David Singer > Manager, Software Standards, Apple Inc. > >
Received on Wednesday, 19 August 2015 06:43:08 UTC