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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 06 October 2016 14:09 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 499FD1296A2 for <perpass@ietfa.amsl.com>; Thu, 6 Oct 2016 07:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Level:
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996, 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 Ygf7zXmmqP_9 for <perpass@ietfa.amsl.com>; Thu, 6 Oct 2016 07:09:30 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9B2129427 for <perpass@ietf.org>; Thu, 6 Oct 2016 07:09:07 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 167EB2009E; Thu, 6 Oct 2016 10:23:01 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 98D346392D; Thu, 6 Oct 2016 10:09:06 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie>
References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <db516334-43ab-e967-cfd5-87d920b65015@filament.com> <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 06 Oct 2016 10:09:06 -0400
Message-ID: <32752.1475762946@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/xOkSKKW0-K-NpJb23vPgtvHyQSE>
Cc: perpass@ietf.org, Peter Saint-Andre - Filament <peter@filament.com>, 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: Thu, 06 Oct 2016 14:09:35 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie>; wrote:
    > So I think this is a recurring theme in various protocols
    > and note that the drafts referenced in this thread overnight
    > [1,2,3,4] total 134 pages of text. So istm that there is
    > scope for a bit of generic guidance on the specific issues
    > about which Peter is asking, i.e. guidance on what kinds
    > of analysis to do when inventing or re-using an identifier
    > in a protocol, and (mainly via reference I'd hope) describing
    > the attack surface created when someone doesn't do that as
    > well as they might.

The anima-bootstrap team spent three calls on this topic this past month.
I think that we may have a "HHGH" problem though (the answer being 42)
  i.e: the question here is not sufficiently specific.

    > If someone was willing to try craft a short I-D addressing
    > the above, that'd I think be a fine thing. Anyone want to
    > volunteer to try that? (If so, replying on or off list is
    > fine.) Or is that a silly idea? (If you think so, then
    > replying on the list is way better:-)

I will volunteer, and I'll do this publically so that you'll hold me to it.
Expect it by draft cut-off date.

I think that I can summarize the situation for bootstrap well.
I don't know if it applies to operation or not, because I don't know what the
situation is for uses.

I think that there are significant operational differences between a BTLE
based *PERSONAL* area network (watch, heart monitor, phone) vs an unencrypted
WIFI at CoffeeShopInc.   The differences are very large, and I find that many
privacy discussions focus on the coffee shop to the exclusion of everything
else.

I also want to point out that MAC randomnization is probably far more
important than anything else because AFAIK, none of the 802.11 or 802.15.4
specifications offer to encrypt the L2 addresses, just the payloads.
(I think, but I'm unsure, that the BTLE L2 does encrypt the L2 addresses)


--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-