Subject: [saag] witch hunt on EUI-48/64

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jul 2014 15:53:00 -0400

The words/feeling that I am experiencing was not really witch hunt.
I was asked after if I was referring to the monty-python _Meaning of Life_
business with: "If it's made out of wood, it's a witch" is where I was going,
and actually it was.
    http://montypython.50webs.com/scripts/Holy_Grail/Scene5.htm

It was more about: http://en.wikipedia.org/wiki/Red_Scare
It feels a bit like there is a IETF Committee on No-Globally-Unique Identifiers
   (akin to the House Committee on Un-American Activities).
In this analogy, the IoT world are American born Asians, looking at internment.

I think that the work that rfc6973 (privacy implications for IP) did is good.
RFC 7217 (Stable Privacy addresses) and draft-ietf-6man-default-iids-00
(make 7217 a SHOULD) are good logical recommendations.

But it now seems like there is a belief that getting rid of every use of
vendor derived EUI-64 is a good thing.

It's interesting that the ESSID scanning attack (which seems like a far more
significant attack on privacy to me) has no dependancy at all on vendor-derived
EUI-64s.... they just need to be stable for zero-zero periods of time.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Huitema <[email-masked]>
Date: Thu, 24 Jul 2014 22:28:44 +0000

> But it now seems like there is a belief that getting rid of every use of vendor derived EUI-64 is a good thing.
>
> It's interesting that the ESSID scanning attack (which seems like a far more significant attack on privacy to me) 
> has no dependancy at all on vendor-derived EUI-64s.... they just need to be stable for zero-zero periods of time.

In as much as the "things" are personal devices, then yes of course we should not use permanent identifiers in the IPv6 addresses. Look at the scenario in which your smart wrist watch periodically communicates with your smart phone in your pocket. The low level protocol layers are probably not encrypted. How long do you believe we need to wait before an enterprising start-up builds a neat radio device that listens to these unencrypted exchanges, extract the unencrypted identifiers, and builds a neat people tracker?

-- Christian Huitema

---

From: Paul Lambert <[email-masked]>
Date: Thu, 24 Jul 2014 16:16:00 -0700

]-----Original Message-----
]From: saag [mailto:[email-masked]] On Behalf Of Christian Huitema
]Sent: Thursday, July 24, 2014 3:29 PM
]To: /dev/[email-masked]; [email-masked]
]Subject: Re: [saag] witch hunt on EUI-48/64
]
]> But it now seems like there is a belief that getting rid of every use
]of vendor derived EUI-64 is a good thing.
]>
]> It's interesting that the ESSID scanning attack (which seems like a
]> far more significant attack on privacy to me) has no dependancy at all
]on vendor-derived EUI-64s.... they just need to be stable for zero-zero
]periods of time.
]
]In as much as the "things" are personal devices, then yes of course we
]should not use permanent identifiers in the IPv6 addresses. Look at the
]scenario in which your smart wrist watch periodically communicates with
]your smart phone in your pocket. The low level protocol layers are
]probably not encrypted. How long do you believe we need to wait before
]an enterprising start-up builds a neat radio device that listens to
]these unencrypted exchanges, extract the unencrypted identifiers, and
]builds a neat people tracker?
These exist already:
	http://tinyurl.com/qdz4t7h 
	http://www.infowars.com/wi-fi-trashcans-now-silently-tracking-your-smartphone-data/ 
	http://arstechnica.com/security/2013/08/diy-stalker-boxes-spy-on-wi-fi-users-cheaply-and-with-maximum-creep-value/
	https://firstlook.org/theintercept/article/2014/02/10/the-nsas-secret-role/

IPv6 then extends the 'local' tracking to be end-to-end when the MAC address is used.

Solutions are being proposed in Layer 2 activates (e.g. IEEE 802) to
mitigate this type of problem by using Ephemeral MAC Addresses.

Paul

]
]-- Christian Huitema
]
]
]_______________________________________________
]saag mailing list
][email-masked]
]https://www.ietf.org/mailman/listinfo/saag