IETF Logo Mail Archive

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

Eitan Adler <lists@eitanadler.com> Fri, 14 October 2016 11:15 UTC

Return-Path: <lists@eitanadler.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 DC9BA12945D for <perpass@ietfa.amsl.com>; Fri, 14 Oct 2016 04:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eitanadler.com
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 Q1m1XA8GDLDl for <perpass@ietfa.amsl.com>; Fri, 14 Oct 2016 04:15:28 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 3C3DE129445 for <perpass@ietf.org>; Fri, 14 Oct 2016 04:15:28 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id s49so69810961qta.0 for <perpass@ietf.org>; Fri, 14 Oct 2016 04:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rwjwwJVif5DMnI0tWSicFWCkoOwm6M4HLKDtzh+W37g=; b=I6+4eUopILy2GMQ+o70uJQ2el39EjoGwKZM6ZREafTtx33J9Zrx0COQq+Hk077cZKH mrU659SAivS1z4I9GamIZpT7A/ylNIyC/OeiOvKro7AY/9QDHQuwmCE9Y1vi0mul4H3c 2M6ZQgMxxDLZ58b0p1E2HJ9NHYJh8VJUbtvnE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rwjwwJVif5DMnI0tWSicFWCkoOwm6M4HLKDtzh+W37g=; b=idUv47utLQcDK5Ws1Ob/aQ6XEi00zNutkuZP2BOTDf8oC7gFoS1LIWDjWgavU2pYE8 NcKt0zOJA6mhxnPOKghHF7SUZE/rvynz1a1B78mjmWOdtH9AhPn5p+WemMZORW6i0sEM 6pNJwKdEcXagqO5Xa6NdME9OMXmxmm77repKZ3ZEQR/wtuw7mG4n8CCLOIkh+MwsZZC+ tJ+nWI3Q6VMErh3RKcxLXgMbslt3x9+IJwWPVZr+vhjyEurQsK7ec7GSonWgczFMs1DF qknEmxRf9aCVwicVIeisgEa7tNUIE4DjD8r3CfMmTos5RN3sHkhST5swkM/WXN2v+xdY gL9A==
X-Gm-Message-State: AA6/9RkgFBy0NtQdRuo9UHw3lXWGJZhNKEdfVVPsh8hbUtBkZ+gpcld8X8GO+a6gbn0J4k+lBwTD+OWpcSEztA==
X-Received: by 10.28.180.85 with SMTP id d82mr1239510wmf.85.1476443727219; Fri, 14 Oct 2016 04:15:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.107.205 with HTTP; Fri, 14 Oct 2016 04:14:56 -0700 (PDT)
In-Reply-To: <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com>
References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <db516334-43ab-e967-cfd5-87d920b65015@filament.com> <CAKr6gn2EjAwqvTXgNyO0Jc3yt9qFRfixXMURHg3wQLe4FcwWWQ@mail.gmail.com> <CY1PR03MB2265659F67817DF02F3FCF29A3C70@CY1PR03MB2265.namprd03.prod.outlook.com> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com>
From: Eitan Adler <lists@eitanadler.com>
Date: Fri, 14 Oct 2016 04:14:56 -0700
Message-ID: <CAF6rxg=+FEtyAysurReaeN+OjdYZHm9Do-kfJkKi__G-86E8Mg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/AsR64aCfMXf9MSfyDd16NSJIb8U>
Cc: "perpass@ietf.org" <perpass@ietf.org>, Peter Saint-Andre - Filament <peter@filament.com>, George Michaelson <ggm@algebras.org>, Dave Thaler <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: Fri, 14 Oct 2016 11:15:30 -0000

On 13 October 2016 at 21:23, Fernando Gont <fgont@si6networks.com> wrote:
> 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...

Though RFC 4941 exists for this particular issue.

-- 
Eitan Adler

v2.23.0 | Report a Bug | By Email