IETF Logo Mail Archive

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

"John Levine" <johnl@taugh.com> Thu, 06 October 2016 02:44 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07B12945D for <perpass@ietfa.amsl.com>; Wed, 5 Oct 2016 19:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hteg1SvwRonG for <perpass@ietfa.amsl.com>; Wed, 5 Oct 2016 19:44:09 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAF2129415 for <perpass@ietf.org>; Wed, 5 Oct 2016 19:44:08 -0700 (PDT)
Received: (qmail 57078 invoked from network); 6 Oct 2016 02:44:06 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 6 Oct 2016 02:44:06 -0000
Date: Thu, 06 Oct 2016 02:43:45 -0000
Message-ID: <20161006024345.20007.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: perpass@ietf.org
In-Reply-To: <CY1PR03MB2265659F67817DF02F3FCF29A3C70@CY1PR03MB2265.namprd03.prod.outlook.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/XJMwBY2g4puXuMoI1RNvl4FHbts>
Cc: dthaler@microsoft.com
Subject: Re: [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: Thu, 06 Oct 2016 02:44:10 -0000

In article <CY1PR03MB2265659F67817DF02F3FCF29A3C70@CY1PR03MB2265.namprd03.prod.outlook.com> you write:
>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.

It's not just that, it's that MACs have a structure and there's a
registry of prefixes so you can look at a MAC and know who the
manufacturer is and usually what kind of device it is.  For example,
prefix 2C-BE-08 is Apple, and anything with that prefix is probably a
Macbook.

If the unique ID is a version 4 UUID with no structure, I'd think
those particular problems would go away.  There may well still be
stuff you can derive from knowing that this device now is the same
as that device then.

R's,
John

v2.23.0 | Report a Bug | By Email