The issue with IEEE MAC's is that it's sent to untrusted observers, not that it is a stable identifier per se. It just so happens that you typically don't have a choice but to send it in packets such that it can be observed by untrusted observers, hence the need to use randomized MACs.
-----Original Message----- From: George Michaelson [mailto:g...@algebras.org] Sent: Wednesday, October 5, 2016 5:01 PM To: Peter Saint-Andre - Filament <pe...@filament.com> Cc: perpass@ietf.org; Dave Thaler <dtha...@microsoft.com> Subject: Re: [perpass] privacy implications of UUIDs for IoT devices As an example the IEEE MAC registry is really only to provide uniqueness, but its been demonstrated to act as a passive-capture mechanism to identify probable host architecture from on-the-wire sniffs. This then leads directly to: "If its a Dell, then I know the iDrac default password so I can attempt to see if this is a badly configured Dell which has iDrac IPMI on the host address" and like attacks. Unique identifiers are being used by the cellular provider to offer price differentiated service to people on the same basic substrate. Which is a poshed-up way of saying you can get a SIM which is dataplan for an iPad but if you put it in your phone you are in breach of contract over the use of that SIM. I am not personally a fan of this legalism, but it is legal, and it is an ism. I think there is a fundamental tension between baked in uniqueness, probabalistic uniqueness (think ULA) and non-unique state in Layer-2 and Layer-3 -G On Thu, Oct 6, 2016 at 9:54 AM, Peter Saint-Andre - Filament <pe...@filament.com> wrote: > Over on the CORE WG list, we've had a little discussion about the > desirability (or not) of unique identifiers for devices in the > Internet of Things. The message below provides some context. > > I'd be curious to learn more about the attack surface lurking behind > Stephen Farrell's comment that having long-term stable identifiers for > IoT devices is a privacy-unfriendly practice because people will abuse such > identifiers. > > To be clear, the scenarios I have in mind are not specific to CoAP and > don't always involve IP-based networking (the technology I'm working > on these days enables mesh networking over long-range radio), but they > do involve discovery and eventual communication that is both > end-to-end encrypted and as close to metadata-hiding as possible. > > Thanks! > > Peter > > -------- Forwarded Message -------- > Subject: Re: [core] Implications of IP address / port changes for CoAP > & Co > Date: Thu, 6 Oct 2016 00:11:26 +0100 > From: Stephen Farrell > To: c...@ietf.org <c...@ietf.org> > > > Hi Peter, > > On 06/10/16 00:03, Peter Saint-Andre - Filament wrote: >> >> On 10/5/16 4:28 PM, Stephen Farrell wrote: >> >>> On 05/10/16 23:22, Dave Thaler wrote: >>>> >>>> It is important that every device have a unique UUID that is >>>> endpoint-address-agnostic and protocol-agnostic. >>> >>> >>> Considering the privacy implications I'm not at all sure I'd accept >>> that argument. In fact I'd argue we ought encourage that devices not >>> have globally unique long-term identifiers at all unless there is a >>> real need for those, and unless we understand how to control their >>> (ab)use. >> >> >> By "identifier" do we necessarily mean "network identifier"? It seems >> to me that it is useful to have a unique long-term identifier for >> every device, based on its public key. Whether you can obtain a >> network connection to that device based on such information is another story. > > > It is undoubtedly useful to have long term stable identifiers of > various kinds. I'd include key IDs and public keys as such. > > Turns out that it's also fairly universally privacy unfriendly as > people will abuse such identifiers for good and bad reasons. > > So I think we need to get much better at analysing when such things > are really needed and in what scope. My bet is that a lot of the time > a locally or probabilistically unique more transient identifier would > be just fine. > > But yeah, I can't prove that. OTOH there is a hint in the term "IMSI > catcher" isn't there? > > Cheers, > S. > >> >> Peter >> > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
