btw, my primary goal was illustrative not specific. persistent ID threats are not exactly like MAC threats, but they probably lie in a similar space. I have no major concern with the desire to be deterministically both unique and known, I have this concern that the mechanisms a manufacturer can use there, tend to processes (IEEE Registry) which construct higher state (vendor-specific blocks) which have side effects.
On Thu, Oct 6, 2016 at 10:09 AM, Dave Thaler <[email protected]> wrote: > 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:[email protected]] > Sent: Wednesday, October 5, 2016 5:01 PM > To: Peter Saint-Andre - Filament <[email protected]> > Cc: [email protected]; Dave Thaler <[email protected]> > 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 > <[email protected]> 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: [email protected] <[email protected]> >> >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
