Re: [perpass] privacy implications of UUIDs for IoT devices

Dave Thaler <> Wed, 05 October 2016 23:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D32312945D for <>; Wed, 5 Oct 2016 16:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.022
X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HP-ZWff7tbb6 for <>; Wed, 5 Oct 2016 16:59:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21A4A1294F7 for <>; Wed, 5 Oct 2016 16:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=acqjUgbu0hF9dUAQJHVIXvGJZG81g8e1N1q4vixWLR0=; b=myALwlYODA5QKFR5lledQ+Qh9YpKUaBpWYMvhUj3KgK9WVKYJBMc1C6BeEVh/Ayud/2RwSDPk9Aa0zifKZSFg0zx8Q5t7BBEs68e2X+WE6gFysze8OqtkfOUR8yt3E32hVQrBNHceSY6gzF5rB28l//QupE8xNm6RbY8Zvhuz9U=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 23:59:10 +0000
Received: from ([]) by ([]) with mapi id 15.01.0649.022; Wed, 5 Oct 2016 23:59:10 +0000
From: Dave Thaler <>
To: Peter Saint-Andre - Filament <>, "" <>
Thread-Topic: privacy implications of UUIDs for IoT devices
Thread-Index: AQHSH2PcWiO88js37E+X2UQbY2LNp6CaiXXw
Date: Wed, 5 Oct 2016 23:59:10 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:8::348]
x-ms-office365-filtering-correlation-id: 5ac0713c-4a13-4af6-16d3-08d3ed7b99d0
x-microsoft-exchange-diagnostics: 1; CY1PR03MB2268; 7:hBeN1Q+sThHLo5JOq1iNEXP/CVIOjVGWqAOgGkcl7XAgEg96zTEVwKa1SmNa116d/cOOwQZhLmNEoXEDU6kA5SP8Qxdj0tA1TiIrGOz1AQzKMIhEDcbTPpamJpViHFitzIQguOj0M20RHfHjLEdM8l+8KJrAATr71yTnP2xpFgGz+i77YZ3JOJ6oTvw/z6HrM466dTk46kc1wIPJLlHCRLf+nKHWFq6og1GZKNs6PiJ5YZkci5IQioOM4haO6h3jEkGpkSOZ43HBGyZpyX+vwqU8feGHvxBZgPsw2oi/zci/AbYSrlMwfoxW+9oQfLHjpIrCOE9UV9aJyy5zM+O7UQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2268;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2268; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2268;
x-forefront-prvs: 008663486A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(13464003)(199003)(24454002)(54356999)(305945005)(101416001)(2950100002)(10400500002)(99286002)(10290500002)(7846002)(7736002)(76176999)(5005710100001)(74316002)(50986999)(33656002)(76576001)(122556002)(8936002)(106116001)(9686002)(19580405001)(19580395003)(106356001)(105586002)(107886002)(8676002)(81166006)(77096005)(15975445007)(68736007)(10090500001)(2900100001)(2501003)(7696004)(5001770100001)(97736004)(189998001)(92566002)(3660700001)(586003)(86362001)(2906002)(5002640100001)(86612001)(11100500001)(87936001)(102836003)(3280700002)(6116002)(8990500004)(81156014)(5660300001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2268;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 23:59:10.4601 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2268
Archived-At: <>
Subject: Re: [perpass] privacy implications of UUIDs for IoT devices
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Oct 2016 23:59:16 -0000 is a short summary I wrote last month about this problem.

-----Original Message-----
From: Peter Saint-Andre - Filament [] 
Sent: Wednesday, October 5, 2016 4:55 PM
Cc: Dave Thaler <>
Subject: privacy implications of UUIDs for IoT devices

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.



-------- 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: <>

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?


> Peter