[perpass] privacy implications of UUIDs for IoT devices

Peter Saint-Andre - Filament <peter@filament.com> Wed, 05 October 2016 23:54 UTC

Return-Path: <peter@filament.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 80E9F1294EF for <perpass@ietfa.amsl.com>; Wed, 5 Oct 2016 16:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9qPfJNB1ORY5 for <perpass@ietfa.amsl.com>; Wed, 5 Oct 2016 16:54:49 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9CD1294EB for <perpass@ietf.org>; Wed, 5 Oct 2016 16:54:48 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id q192so3098593iod.0 for <perpass@ietf.org>; Wed, 05 Oct 2016 16:54:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ardbI3Gt2ZNJVtK+zUX65hlRC9SXHRWIwhXRMbntpqk=; b=SrWSHlDqESdYpp9gu8LvuCVdKiku03hRg2PXzbB3zxhU7IULh2ekYLTuvQkQlW4+HQ /Hu/BdUow+Q4PyikhugXIQQO3Bvh+HYqmGatZJCRcbxLyrLexh+bZZlpanju18CXxlc6 Frjn/oJ7XkhOaXpLAM2xQ5zcOI9J1o6VXVtjzV7hVa4oESsFdmTl3ob4t/HuFI2tBZVD /I6WWw86MHQaNMqPqdSOouv2x2D/xovihG7Tt0IBmWSGX8p0M4HUbvIpQfKMvUIfmRs8 thv/gJa8xw7+2yAIhwYPq1FUKxwtTNIwdVVmsV7D9LxFKBnZEmhvdD/aHg0VDSkeH7QT 7hkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ardbI3Gt2ZNJVtK+zUX65hlRC9SXHRWIwhXRMbntpqk=; b=dVDS+hLx0h+1kK+CcJwEdzM8OyJPXD8V/nHU63Ji2NE9zR+LY7yn5jAJJEzIyvPUvu +mJ+rDRoILgEhto9PY4bRQ0p5OyRIBrKT4o1AFbtnRVtFtZPn2JXdIoOC7bitgdGs36a 83puRn+JagYe3YcPOYFAgB/K4UEkyt2htdrdPQNexfgmxCnGSurqDoeyJW4AbSDvSA5A 8843uScWO+ped0uY96MjVtKMUNT3LiXk6H/opB9hw+K7L2Wf7/YXCGuMFc7WqvRHTdIw +pwyksUNqh+hQezLnZGGN/z5PTj/aQzsQsPGChv42vh65QdfwgKkFO9Aeg8zy7FoIi7n L50A==
X-Gm-Message-State: AA6/9RnxNY5NL0ULkhsHPjhBnFjzwZvX+jHhzhfhj4pzOWOAfycvw46lLd5ybHE1oX4EPg==
X-Received: by with SMTP id x82mr11826783iod.197.1475711688205; Wed, 05 Oct 2016 16:54:48 -0700 (PDT)
Received: from aither.local ([]) by smtp.gmail.com with ESMTPSA id j194sm4558014ioe.39.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:54:47 -0700 (PDT)
References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie>
To: perpass@ietf.org
From: Peter Saint-Andre - Filament <peter@filament.com>
X-Forwarded-Message-Id: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie>
Message-ID: <db516334-43ab-e967-cfd5-87d920b65015@filament.com>
Date: Wed, 5 Oct 2016 17:54:46 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/i3djUQopTtC35LEHSDOpAtY22Jg>
Cc: Dave Thaler <dthaler@microsoft.com>
Subject: [perpass] privacy implications of UUIDs for IoT devices
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 23:54:50 -0000

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: core@ietf.org <core@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?


> Peter