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

Fernando Gont <> Fri, 14 October 2016 10:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BCDF129703 for <>; Fri, 14 Oct 2016 03:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.358
X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FB1F3cme54My for <>; Fri, 14 Oct 2016 03:26:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 761B01296FD for <>; Fri, 14 Oct 2016 03:26:05 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 01F1681A44; Fri, 14 Oct 2016 12:25:59 +0200 (CEST)
To: Dave Thaler <>, George Michaelson <>, Peter Saint-Andre - Filament <>
References: <> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 14 Oct 2016 01:23:28 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>
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: Fri, 14 Oct 2016 10:26:27 -0000

On 10/05/2016 09:09 PM, Dave Thaler 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.

The issue with MAC addresses is that they are constant across networks
when, if anything, they just need to be stable within the same subnet.

Besides, they have semantics (vendor ID) when in fact they need not.

And well, the problem is exacerbated by IPv6 SLAAC traditionally
generating IPv6 IIDs by embedding the underlying MAC address into them...

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492