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

George Michaelson <> Thu, 06 October 2016 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C47512944B for <>; Wed, 5 Oct 2016 17:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t2OYWR4IVP3G for <>; Wed, 5 Oct 2016 17:01:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC0EB129404 for <>; Wed, 5 Oct 2016 17:01:16 -0700 (PDT)
Received: by with SMTP id 2so136833vkb.1 for <>; Wed, 05 Oct 2016 17:01:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VxcBGy5p7BXC2zWKvegCV0WH4rXwg5rNhxARqmUNOXU=; b=PQ5AfrQhbbpvMsxiNdtqjUAEH7gwrzvPdHRmgd/CxXeXctPhK96rjBZjgBgjRIJdpR 9pYF4/MdC7GKW+s0L+YLNFy8nn8KnxkCjk2lUcV1cBBxBQlx/IzXRfUqiYb8JmqYAFuS TLXtbkocF+wn0IeLTdDE0GnNe4mUs5mCo/4DZZB4C6hk85o6qYb9H5hokW5L95/24rUX YJhaEfHokstUvpooh48j+Ri2bz+Gkb0NiBs/1DnNTJYA4v3Rls/cDtIenwUJ8yOyeZir 0Knx6L8dC2lv/o4UoGWuHS1REZcaIfSN9iIEix6JY4eT7PGOJ+iCMvpdqlnAUaGcDAIZ WrIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VxcBGy5p7BXC2zWKvegCV0WH4rXwg5rNhxARqmUNOXU=; b=P97W3B1usDHJo2uZ0ZEAJlH90vQRv6kd0Gfs5sXujkjMcWtsUooJh+Kodzz9ZTsUbA ggFkXnZVKwIo0qOrLtSQtCae6IXhA11PQGvv0S6CIJHoYYiorB2qtpWvhtZcSW3V9RKu 4MINIAQJCl70ZPIgYws+mPusRSMTNIoKP+hxEJbNSgGjk6nTWxCZpOD0XdlBgwP30B6o y6KWqj/Uo8Xx/f8xllkBzdUIrANS7GQMoGxRHXNVKTfMeYzh5Ls2Y++I396dm6ywoPrZ pbr+gUYRO6nR5OXiSpzHOGgLDPvj95xDnjVD0nF6RDgRUxZ7ivJjKJepW6wB/lqZVBaW 6Wug==
X-Gm-Message-State: AA6/9RnAgexrbzQ3V90RuTXhhhO14xSD4n8Al6Sqt+MrXpiY9cESxKnQ/WYbeie/MJweH3sYRifArb1ZLpyN3Q==
X-Received: by with SMTP id m67mr9224703vkg.43.1475712075930; Wed, 05 Oct 2016 17:01:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 5 Oct 2016 17:01:15 -0700 (PDT)
X-Originating-IP: [2001:dc0:a000:4:29c6:ab71:9f28:4d0a]
In-Reply-To: <>
References: <> <>
From: George Michaelson <>
Date: Thu, 6 Oct 2016 10:01:15 +1000
Message-ID: <>
To: Peter Saint-Andre - Filament <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>, Dave Thaler <>
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: Thu, 06 Oct 2016 00:01:19 -0000

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

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


On Thu, Oct 6, 2016 at 9:54 AM, Peter Saint-Andre - Filament
<> 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: <>
> 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