From nobody Wed Oct 5 16:54:52 2016 Return-Path: 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 80E9F1294EF for ; Wed, 5 Oct 2016 16:54:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.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 9qPfJNB1ORY5 for ; Wed, 5 Oct 2016 16:54:49 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 DA9CD1294EB for ; Wed, 5 Oct 2016 16:54:48 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q192so3098593iod.0 for ; Wed, 05 Oct 2016 16:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ardbI3Gt2ZNJVtK+zUX65hlRC9SXHRWIwhXRMbntpqk=; b=SrWSHlDqESdYpp9gu8LvuCVdKiku03hRg2PXzbB3zxhU7IULh2ekYLTuvQkQlW4+HQ /Hu/BdUow+Q4PyikhugXIQQO3Bvh+HYqmGatZJCRcbxLyrLexh+bZZlpanju18CXxlc6 Frjn/oJ7XkhOaXpLAM2xQ5zcOI9J1o6VXVtjzV7hVa4oESsFdmTl3ob4t/HuFI2tBZVD /I6WWw86MHQaNMqPqdSOouv2x2D/xovihG7Tt0IBmWSGX8p0M4HUbvIpQfKMvUIfmRs8 thv/gJa8xw7+2yAIhwYPq1FUKxwtTNIwdVVmsV7D9LxFKBnZEmhvdD/aHg0VDSkeH7QT 7hkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ardbI3Gt2ZNJVtK+zUX65hlRC9SXHRWIwhXRMbntpqk=; b=dVDS+hLx0h+1kK+CcJwEdzM8OyJPXD8V/nHU63Ji2NE9zR+LY7yn5jAJJEzIyvPUvu +mJ+rDRoILgEhto9PY4bRQ0p5OyRIBrKT4o1AFbtnRVtFtZPn2JXdIoOC7bitgdGs36a 83puRn+JagYe3YcPOYFAgB/K4UEkyt2htdrdPQNexfgmxCnGSurqDoeyJW4AbSDvSA5A 8843uScWO+ped0uY96MjVtKMUNT3LiXk6H/opB9hw+K7L2Wf7/YXCGuMFc7WqvRHTdIw +pwyksUNqh+hQezLnZGGN/z5PTj/aQzsQsPGChv42vh65QdfwgKkFO9Aeg8zy7FoIi7n L50A== X-Gm-Message-State: AA6/9RnxNY5NL0ULkhsHPjhBnFjzwZvX+jHhzhfhj4pzOWOAfycvw46lLd5ybHE1oX4EPg== X-Received: by 10.107.149.85 with SMTP id x82mr11826783iod.197.1475711688205; Wed, 05 Oct 2016 16:54:48 -0700 (PDT) Received: from aither.local ([76.25.4.24]) by smtp.gmail.com with ESMTPSA id j194sm4558014ioe.39.2016.10.05.16.54.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 16:54:47 -0700 (PDT) References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> To: perpass@ietf.org From: Peter Saint-Andre - Filament X-Forwarded-Message-Id: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> Message-ID: Date: Wed, 5 Oct 2016 17:54:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Dave Thaler Subject: [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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 23:54:50 -0000 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: core@ietf.org 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 > From nobody Wed Oct 5 16:59:18 2016 Return-Path: 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 0D32312945D for ; Wed, 5 Oct 2016 16:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 HP-ZWff7tbb6 for ; Wed, 5 Oct 2016 16:59:12 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0118.outbound.protection.outlook.com [104.47.42.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A4A1294F7 for ; Wed, 5 Oct 2016 16:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=acqjUgbu0hF9dUAQJHVIXvGJZG81g8e1N1q4vixWLR0=; b=myALwlYODA5QKFR5lledQ+Qh9YpKUaBpWYMvhUj3KgK9WVKYJBMc1C6BeEVh/Ayud/2RwSDPk9Aa0zifKZSFg0zx8Q5t7BBEs68e2X+WE6gFysze8OqtkfOUR8yt3E32hVQrBNHceSY6gzF5rB28l//QupE8xNm6RbY8Zvhuz9U= Received: from CY1PR03MB2265.namprd03.prod.outlook.com (10.166.207.17) by CY1PR03MB2268.namprd03.prod.outlook.com (10.166.207.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 23:59:10 +0000 Received: from CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) by CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) with mapi id 15.01.0649.022; Wed, 5 Oct 2016 23:59:10 +0000 From: Dave Thaler To: Peter Saint-Andre - Filament , "perpass@ietf.org" Thread-Topic: privacy implications of UUIDs for IoT devices Thread-Index: AQHSH2PcWiO88js37E+X2UQbY2LNp6CaiXXw Date: Wed, 5 Oct 2016 23:59:10 +0000 Message-ID: References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:8::348] x-ms-office365-filtering-correlation-id: 5ac0713c-4a13-4af6-16d3-08d3ed7b99d0 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2268; 7:hBeN1Q+sThHLo5JOq1iNEXP/CVIOjVGWqAOgGkcl7XAgEg96zTEVwKa1SmNa116d/cOOwQZhLmNEoXEDU6kA5SP8Qxdj0tA1TiIrGOz1AQzKMIhEDcbTPpamJpViHFitzIQguOj0M20RHfHjLEdM8l+8KJrAATr71yTnP2xpFgGz+i77YZ3JOJ6oTvw/z6HrM466dTk46kc1wIPJLlHCRLf+nKHWFq6og1GZKNs6PiJ5YZkci5IQioOM4haO6h3jEkGpkSOZ43HBGyZpyX+vwqU8feGHvxBZgPsw2oi/zci/AbYSrlMwfoxW+9oQfLHjpIrCOE9UV9aJyy5zM+O7UQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2268; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2268; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(13464003)(199003)(24454002)(54356999)(305945005)(101416001)(2950100002)(10400500002)(99286002)(10290500002)(7846002)(7736002)(76176999)(5005710100001)(74316002)(50986999)(33656002)(76576001)(122556002)(8936002)(106116001)(9686002)(19580405001)(19580395003)(106356001)(105586002)(107886002)(8676002)(81166006)(77096005)(15975445007)(68736007)(10090500001)(2900100001)(2501003)(7696004)(5001770100001)(97736004)(189998001)(92566002)(3660700001)(586003)(86362001)(2906002)(5002640100001)(86612001)(11100500001)(87936001)(102836003)(3280700002)(6116002)(8990500004)(81156014)(5660300001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2268; H:CY1PR03MB2265.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 23:59:10.4601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2268 Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 23:59:16 -0000 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRoYWxlci1jb3JlLXJlZGlyZWN0LTAw I3NlY3Rpb24tMSBpcyBhIHNob3J0IHN1bW1hcnkgSSB3cm90ZSBsYXN0IG1vbnRoIGFib3V0IHRo aXMgcHJvYmxlbS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBldGVyIFNh aW50LUFuZHJlIC0gRmlsYW1lbnQgW21haWx0bzpwZXRlckBmaWxhbWVudC5jb21dIA0KU2VudDog V2VkbmVzZGF5LCBPY3RvYmVyIDUsIDIwMTYgNDo1NSBQTQ0KVG86IHBlcnBhc3NAaWV0Zi5vcmcN CkNjOiBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogcHJpdmFj eSBpbXBsaWNhdGlvbnMgb2YgVVVJRHMgZm9yIElvVCBkZXZpY2VzDQoNCk92ZXIgb24gdGhlIENP UkUgV0cgbGlzdCwgd2UndmUgaGFkIGEgbGl0dGxlIGRpc2N1c3Npb24gYWJvdXQgdGhlIGRlc2ly YWJpbGl0eSAob3Igbm90KSBvZiB1bmlxdWUgaWRlbnRpZmllcnMgZm9yIGRldmljZXMgaW4gdGhl IEludGVybmV0IG9mIFRoaW5ncy4gVGhlIG1lc3NhZ2UgYmVsb3cgcHJvdmlkZXMgc29tZSBjb250 ZXh0Lg0KDQpJJ2QgYmUgY3VyaW91cyB0byBsZWFybiBtb3JlIGFib3V0IHRoZSBhdHRhY2sgc3Vy ZmFjZSBsdXJraW5nIGJlaGluZCBTdGVwaGVuIEZhcnJlbGwncyBjb21tZW50IHRoYXQgaGF2aW5n IGxvbmctdGVybSBzdGFibGUgaWRlbnRpZmllcnMgZm9yIElvVCBkZXZpY2VzIGlzIGEgcHJpdmFj eS11bmZyaWVuZGx5IHByYWN0aWNlIGJlY2F1c2UgcGVvcGxlIHdpbGwgYWJ1c2Ugc3VjaCBpZGVu dGlmaWVycy4NCg0KVG8gYmUgY2xlYXIsIHRoZSBzY2VuYXJpb3MgSSBoYXZlIGluIG1pbmQgYXJl IG5vdCBzcGVjaWZpYyB0byBDb0FQIGFuZCBkb24ndCBhbHdheXMgaW52b2x2ZSBJUC1iYXNlZCBu ZXR3b3JraW5nICh0aGUgdGVjaG5vbG9neSBJJ20gd29ya2luZyBvbiB0aGVzZSBkYXlzIGVuYWJs ZXMgbWVzaCBuZXR3b3JraW5nIG92ZXIgbG9uZy1yYW5nZSByYWRpbyksIGJ1dCB0aGV5IGRvIGlu dm9sdmUgZGlzY292ZXJ5IGFuZCBldmVudHVhbCBjb21tdW5pY2F0aW9uIHRoYXQgaXMgYm90aCBl bmQtdG8tZW5kIGVuY3J5cHRlZCBhbmQgYXMgY2xvc2UgdG8gbWV0YWRhdGEtaGlkaW5nIGFzIHBv c3NpYmxlLg0KDQpUaGFua3MhDQoNClBldGVyDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdl IC0tLS0tLS0tDQpTdWJqZWN0OiBSZTogW2NvcmVdIEltcGxpY2F0aW9ucyBvZiBJUCBhZGRyZXNz IC8gcG9ydCBjaGFuZ2VzIGZvciBDb0FQICYgQ28NCkRhdGU6IFRodSwgNiBPY3QgMjAxNiAwMDox MToyNiArMDEwMA0KRnJvbTogU3RlcGhlbiBGYXJyZWxsDQpUbzogY29yZUBpZXRmLm9yZyA8Y29y ZUBpZXRmLm9yZz4NCg0KDQpIaSBQZXRlciwNCg0KT24gMDYvMTAvMTYgMDA6MDMsIFBldGVyIFNh aW50LUFuZHJlIC0gRmlsYW1lbnQgd3JvdGU6DQo+IE9uIDEwLzUvMTYgNDoyOCBQTSwgU3RlcGhl biBGYXJyZWxsIHdyb3RlOg0KPg0KPj4gT24gMDUvMTAvMTYgMjM6MjIsIERhdmUgVGhhbGVyIHdy b3RlOg0KPj4+IEl0IGlzIGltcG9ydGFudCB0aGF0IGV2ZXJ5IGRldmljZSBoYXZlIGEgdW5pcXVl IFVVSUQgdGhhdCBpcyANCj4+PiBlbmRwb2ludC1hZGRyZXNzLWFnbm9zdGljIGFuZCBwcm90b2Nv bC1hZ25vc3RpYy4NCj4+DQo+PiBDb25zaWRlcmluZyB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMg SSdtIG5vdCBhdCBhbGwgc3VyZSBJJ2QgYWNjZXB0IA0KPj4gdGhhdCBhcmd1bWVudC4gSW4gZmFj dCBJJ2QgYXJndWUgd2Ugb3VnaHQgZW5jb3VyYWdlIHRoYXQgZGV2aWNlcyBub3QgDQo+PiBoYXZl IGdsb2JhbGx5IHVuaXF1ZSBsb25nLXRlcm0gaWRlbnRpZmllcnMgYXQgYWxsIHVubGVzcyB0aGVy ZSBpcyBhIA0KPj4gcmVhbCBuZWVkIGZvciB0aG9zZSwgYW5kIHVubGVzcyB3ZSB1bmRlcnN0YW5k IGhvdyB0byBjb250cm9sIHRoZWlyIA0KPj4gKGFiKXVzZS4NCj4NCj4gQnkgImlkZW50aWZpZXIi IGRvIHdlIG5lY2Vzc2FyaWx5IG1lYW4gIm5ldHdvcmsgaWRlbnRpZmllciI/IEl0IHNlZW1zIA0K PiB0byBtZSB0aGF0IGl0IGlzIHVzZWZ1bCB0byBoYXZlIGEgdW5pcXVlIGxvbmctdGVybSBpZGVu dGlmaWVyIGZvciANCj4gZXZlcnkgZGV2aWNlLCBiYXNlZCBvbiBpdHMgcHVibGljIGtleS4gV2hl dGhlciB5b3UgY2FuIG9idGFpbiBhIA0KPiBuZXR3b3JrIGNvbm5lY3Rpb24gdG8gdGhhdCBkZXZp Y2UgYmFzZWQgb24gc3VjaCBpbmZvcm1hdGlvbiBpcyBhbm90aGVyIHN0b3J5Lg0KDQpJdCBpcyB1 bmRvdWJ0ZWRseSB1c2VmdWwgdG8gaGF2ZSBsb25nIHRlcm0gc3RhYmxlIGlkZW50aWZpZXJzIG9m IHZhcmlvdXMga2luZHMuIEknZCBpbmNsdWRlIGtleSBJRHMgYW5kIHB1YmxpYyBrZXlzIGFzIHN1 Y2guDQoNClR1cm5zIG91dCB0aGF0IGl0J3MgYWxzbyBmYWlybHkgdW5pdmVyc2FsbHkgcHJpdmFj eSB1bmZyaWVuZGx5IGFzIHBlb3BsZSB3aWxsIGFidXNlIHN1Y2ggaWRlbnRpZmllcnMgZm9yIGdv b2QgYW5kIGJhZCByZWFzb25zLg0KDQpTbyBJIHRoaW5rIHdlIG5lZWQgdG8gZ2V0IG11Y2ggYmV0 dGVyIGF0IGFuYWx5c2luZyB3aGVuIHN1Y2ggdGhpbmdzIGFyZSByZWFsbHkgbmVlZGVkIGFuZCBp biB3aGF0IHNjb3BlLiBNeSBiZXQgaXMgdGhhdCBhIGxvdCBvZiB0aGUgdGltZSBhIGxvY2FsbHkg b3IgcHJvYmFiaWxpc3RpY2FsbHkgdW5pcXVlIG1vcmUgdHJhbnNpZW50IGlkZW50aWZpZXIgd291 bGQgYmUganVzdCBmaW5lLg0KDQpCdXQgeWVhaCwgSSBjYW4ndCBwcm92ZSB0aGF0LiBPVE9IIHRo ZXJlIGlzIGEgaGludCBpbiB0aGUgdGVybSAiSU1TSSBjYXRjaGVyIiBpc24ndCB0aGVyZT8NCg0K Q2hlZXJzLA0KUy4NCg0KPg0KPiBQZXRlcg0KPg0KDQo= From nobody Wed Oct 5 17:01:20 2016 Return-Path: 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 6C47512944B for ; Wed, 5 Oct 2016 17:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 t2OYWR4IVP3G for ; Wed, 5 Oct 2016 17:01:17 -0700 (PDT) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (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 CC0EB129404 for ; Wed, 5 Oct 2016 17:01:16 -0700 (PDT) Received: by mail-vk0-x242.google.com 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; d=algebras-org.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.31.213.70 with SMTP id m67mr9224703vkg.43.1475712075930; Wed, 05 Oct 2016 17:01:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.95.5 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: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> 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: "perpass@ietf.org" , Dave Thaler 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. " 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 attacks. 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 -G 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: core@ietf.org > > > 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 > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Wed Oct 5 17:09:16 2016 Return-Path: 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 15BA11294CC for ; Wed, 5 Oct 2016 17:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 WtTDIMbZhxZN for ; Wed, 5 Oct 2016 17:09:12 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0118.outbound.protection.outlook.com [104.47.40.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B749E129442 for ; Wed, 5 Oct 2016 17:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O4jT3CLrWWtgg9Y6g0yuJtS3jctSNPaSQYqUWncev8s=; b=VfDkkbujbmJU3AofCj3Praf6YdRsFSQ8uL5hS9VQHkoiMxMu3pSCz4qhhVajbwC2vbc1sxcXvSlT+qOnqjIbheqGgNIUQ0rXBlq1KH7orLkJJqxAEK08JLFEu1D1yFZmu3/v/6ST8NI20lGQyp6cT3exf1kS2arz2JDOtgOkVGo= Received: from CY1PR03MB2265.namprd03.prod.outlook.com (10.166.207.17) by CY1PR03MB2267.namprd03.prod.outlook.com (10.166.207.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Thu, 6 Oct 2016 00:09:11 +0000 Received: from CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) by CY1PR03MB2265.namprd03.prod.outlook.com ([10.166.207.17]) with mapi id 15.01.0649.022; Thu, 6 Oct 2016 00:09:11 +0000 From: Dave Thaler To: George Michaelson , Peter Saint-Andre - Filament Thread-Topic: [perpass] privacy implications of UUIDs for IoT devices Thread-Index: AQHSH2PcWiO88js37E+X2UQbY2LNp6CairuAgAABetA= Date: Thu, 6 Oct 2016 00:09:11 +0000 Message-ID: References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:8::348] x-ms-office365-filtering-correlation-id: 5e787838-2f49-419f-140a-08d3ed7cffe0 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2267; 7:P7VTHMrJs52jY3Sxn4DrQ8tIwxjBzPlggCtaGQi8XSHD2u9aiANHr41HQK8cj4ZDg1F+FpdfFvB6d6Mw0MOCDYRWLTIgf+eStlW6RkCEtg8TIC0yVxPyG6XKBjfNc7xg6ghqHUoTrmOEEmUSj4Rw3VUentjJLjTfeu7Op/dBQ4wd6gcwvqBNYD+fuz5gHDRXk69dM3sYU7d3yi/xSYRDzglxSMhlc0HOCOveJe8duJkqnZLwkSi0nFfo1RCcPlhXJhe8LI6a9JAfOdBXiIkQIJWcha2bcYXkNCmct6lIasQPm+2Lb1aY+T2nZ38vkasC8MnFhx0IOSKko22C+mHWGQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2267; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2267; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2267; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(199003)(24454002)(189002)(5001770100001)(7846002)(3660700001)(551544002)(11100500001)(87936001)(586003)(7736002)(86612001)(122556002)(9686002)(19580395003)(102836003)(4326007)(74316002)(305945005)(6116002)(8936002)(76576001)(106116001)(81166006)(81156014)(10290500002)(33656002)(54356999)(92566002)(68736007)(5005710100001)(10400500002)(101416001)(19580405001)(97736004)(2906002)(3280700002)(76176999)(106356001)(50986999)(99286002)(15975445007)(8990500004)(2950100002)(2900100001)(77096005)(5660300001)(5002640100001)(10090500001)(7696004)(189998001)(86362001)(8676002)(105586002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2267; H:CY1PR03MB2265.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 00:09:11.1462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2267 Archived-At: Cc: "perpass@ietf.org" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 00:09:15 -0000 VGhlIGlzc3VlIHdpdGggSUVFRSBNQUMncyBpcyB0aGF0IGl0J3Mgc2VudCB0byB1bnRydXN0ZWQg b2JzZXJ2ZXJzLCBub3QgdGhhdCBpdCBpcyBhIHN0YWJsZSBpZGVudGlmaWVyIHBlciBzZS4NCkl0 IGp1c3Qgc28gaGFwcGVucyB0aGF0IHlvdSB0eXBpY2FsbHkgZG9uJ3QgaGF2ZSBhIGNob2ljZSBi dXQgdG8gc2VuZCBpdCBpbiBwYWNrZXRzIHN1Y2ggdGhhdCBpdCBjYW4gYmUgb2JzZXJ2ZWQNCmJ5 IHVudHJ1c3RlZCBvYnNlcnZlcnMsIGhlbmNlIHRoZSBuZWVkIHRvIHVzZSByYW5kb21pemVkIE1B Q3MuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHZW9yZ2UgTWljaGFlbHNv biBbbWFpbHRvOmdnbUBhbGdlYnJhcy5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDUs IDIwMTYgNTowMSBQTQ0KVG86IFBldGVyIFNhaW50LUFuZHJlIC0gRmlsYW1lbnQgPHBldGVyQGZp bGFtZW50LmNvbT4NCkNjOiBwZXJwYXNzQGlldGYub3JnOyBEYXZlIFRoYWxlciA8ZHRoYWxlckBt aWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmU6IFtwZXJwYXNzXSBwcml2YWN5IGltcGxpY2F0aW9u cyBvZiBVVUlEcyBmb3IgSW9UIGRldmljZXMNCg0KQXMgYW4gZXhhbXBsZSB0aGUgSUVFRSBNQUMg cmVnaXN0cnkgaXMgcmVhbGx5IG9ubHkgdG8gcHJvdmlkZSB1bmlxdWVuZXNzLCBidXQgaXRzIGJl ZW4gZGVtb25zdHJhdGVkIHRvIGFjdCBhcyBhIHBhc3NpdmUtY2FwdHVyZSBtZWNoYW5pc20gdG8g aWRlbnRpZnkgcHJvYmFibGUgaG9zdCBhcmNoaXRlY3R1cmUgZnJvbSBvbi10aGUtd2lyZSBzbmlm ZnMuIFRoaXMgdGhlbiBsZWFkcyBkaXJlY3RseSB0bzogIklmIGl0cyBhIERlbGwsIHRoZW4gSSBr bm93IHRoZSBpRHJhYyBkZWZhdWx0IHBhc3N3b3JkIHNvIEkgY2FuIGF0dGVtcHQgdG8gc2VlIGlm IHRoaXMgaXMgYSBiYWRseSBjb25maWd1cmVkIERlbGwgd2hpY2ggaGFzIGlEcmFjIElQTUkgb24g dGhlIGhvc3QgYWRkcmVzcyIgYW5kIGxpa2UgYXR0YWNrcy4NCg0KVW5pcXVlIGlkZW50aWZpZXJz IGFyZSBiZWluZyB1c2VkIGJ5IHRoZSBjZWxsdWxhciBwcm92aWRlciB0byBvZmZlciBwcmljZSBk aWZmZXJlbnRpYXRlZCBzZXJ2aWNlIHRvIHBlb3BsZSBvbiB0aGUgc2FtZSBiYXNpYyBzdWJzdHJh dGUuDQpXaGljaCBpcyBhIHBvc2hlZC11cCB3YXkgb2Ygc2F5aW5nIHlvdSBjYW4gZ2V0IGEgU0lN IHdoaWNoIGlzIGRhdGFwbGFuIGZvciBhbiBpUGFkIGJ1dCBpZiB5b3UgcHV0IGl0IGluIHlvdXIg cGhvbmUgeW91IGFyZSBpbiBicmVhY2ggb2YgY29udHJhY3Qgb3ZlciB0aGUgdXNlIG9mIHRoYXQg U0lNLiBJIGFtIG5vdCBwZXJzb25hbGx5IGEgZmFuIG9mIHRoaXMgbGVnYWxpc20sIGJ1dCBpdCBp cyBsZWdhbCwgYW5kIGl0IGlzIGFuIGlzbS4NCg0KSSB0aGluayB0aGVyZSBpcyBhIGZ1bmRhbWVu dGFsIHRlbnNpb24gYmV0d2VlbiBiYWtlZCBpbiB1bmlxdWVuZXNzLCBwcm9iYWJhbGlzdGljIHVu aXF1ZW5lc3MgKHRoaW5rIFVMQSkgYW5kIG5vbi11bmlxdWUgc3RhdGUgaW4gTGF5ZXItMiBhbmQg TGF5ZXItMw0KDQotRw0KDQpPbiBUaHUsIE9jdCA2LCAyMDE2IGF0IDk6NTQgQU0sIFBldGVyIFNh aW50LUFuZHJlIC0gRmlsYW1lbnQgPHBldGVyQGZpbGFtZW50LmNvbT4gd3JvdGU6DQo+IE92ZXIg b24gdGhlIENPUkUgV0cgbGlzdCwgd2UndmUgaGFkIGEgbGl0dGxlIGRpc2N1c3Npb24gYWJvdXQg dGhlIA0KPiBkZXNpcmFiaWxpdHkgKG9yIG5vdCkgb2YgdW5pcXVlIGlkZW50aWZpZXJzIGZvciBk ZXZpY2VzIGluIHRoZSANCj4gSW50ZXJuZXQgb2YgVGhpbmdzLiBUaGUgbWVzc2FnZSBiZWxvdyBw cm92aWRlcyBzb21lIGNvbnRleHQuDQo+DQo+IEknZCBiZSBjdXJpb3VzIHRvIGxlYXJuIG1vcmUg YWJvdXQgdGhlIGF0dGFjayBzdXJmYWNlIGx1cmtpbmcgYmVoaW5kIA0KPiBTdGVwaGVuIEZhcnJl bGwncyBjb21tZW50IHRoYXQgaGF2aW5nIGxvbmctdGVybSBzdGFibGUgaWRlbnRpZmllcnMgZm9y IA0KPiBJb1QgZGV2aWNlcyBpcyBhIHByaXZhY3ktdW5mcmllbmRseSBwcmFjdGljZSBiZWNhdXNl IHBlb3BsZSB3aWxsIGFidXNlIHN1Y2ggaWRlbnRpZmllcnMuDQo+DQo+IFRvIGJlIGNsZWFyLCB0 aGUgc2NlbmFyaW9zIEkgaGF2ZSBpbiBtaW5kIGFyZSBub3Qgc3BlY2lmaWMgdG8gQ29BUCBhbmQg DQo+IGRvbid0IGFsd2F5cyBpbnZvbHZlIElQLWJhc2VkIG5ldHdvcmtpbmcgKHRoZSB0ZWNobm9s b2d5IEknbSB3b3JraW5nIA0KPiBvbiB0aGVzZSBkYXlzIGVuYWJsZXMgbWVzaCBuZXR3b3JraW5n IG92ZXIgbG9uZy1yYW5nZSByYWRpbyksIGJ1dCB0aGV5IA0KPiBkbyBpbnZvbHZlIGRpc2NvdmVy eSBhbmQgZXZlbnR1YWwgY29tbXVuaWNhdGlvbiB0aGF0IGlzIGJvdGggDQo+IGVuZC10by1lbmQg ZW5jcnlwdGVkIGFuZCBhcyBjbG9zZSB0byBtZXRhZGF0YS1oaWRpbmcgYXMgcG9zc2libGUuDQo+ DQo+IFRoYW5rcyENCj4NCj4gUGV0ZXINCj4NCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2Ug LS0tLS0tLS0NCj4gU3ViamVjdDogUmU6IFtjb3JlXSBJbXBsaWNhdGlvbnMgb2YgSVAgYWRkcmVz cyAvIHBvcnQgY2hhbmdlcyBmb3IgQ29BUCANCj4gJiBDbw0KPiBEYXRlOiBUaHUsIDYgT2N0IDIw MTYgMDA6MTE6MjYgKzAxMDANCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+IFRvOiBjb3JlQGll dGYub3JnIDxjb3JlQGlldGYub3JnPg0KPg0KPg0KPiBIaSBQZXRlciwNCj4NCj4gT24gMDYvMTAv MTYgMDA6MDMsIFBldGVyIFNhaW50LUFuZHJlIC0gRmlsYW1lbnQgd3JvdGU6DQo+Pg0KPj4gT24g MTAvNS8xNiA0OjI4IFBNLCBTdGVwaGVuIEZhcnJlbGwgd3JvdGU6DQo+Pg0KPj4+IE9uIDA1LzEw LzE2IDIzOjIyLCBEYXZlIFRoYWxlciB3cm90ZToNCj4+Pj4NCj4+Pj4gSXQgaXMgaW1wb3J0YW50 IHRoYXQgZXZlcnkgZGV2aWNlIGhhdmUgYSB1bmlxdWUgVVVJRCB0aGF0IGlzIA0KPj4+PiBlbmRw b2ludC1hZGRyZXNzLWFnbm9zdGljIGFuZCBwcm90b2NvbC1hZ25vc3RpYy4NCj4+Pg0KPj4+DQo+ Pj4gQ29uc2lkZXJpbmcgdGhlIHByaXZhY3kgaW1wbGljYXRpb25zIEknbSBub3QgYXQgYWxsIHN1 cmUgSSdkIGFjY2VwdCANCj4+PiB0aGF0IGFyZ3VtZW50LiBJbiBmYWN0IEknZCBhcmd1ZSB3ZSBv dWdodCBlbmNvdXJhZ2UgdGhhdCBkZXZpY2VzIG5vdCANCj4+PiBoYXZlIGdsb2JhbGx5IHVuaXF1 ZSBsb25nLXRlcm0gaWRlbnRpZmllcnMgYXQgYWxsIHVubGVzcyB0aGVyZSBpcyBhIA0KPj4+IHJl YWwgbmVlZCBmb3IgdGhvc2UsIGFuZCB1bmxlc3Mgd2UgdW5kZXJzdGFuZCBob3cgdG8gY29udHJv bCB0aGVpciANCj4+PiAoYWIpdXNlLg0KPj4NCj4+DQo+PiBCeSAiaWRlbnRpZmllciIgZG8gd2Ug bmVjZXNzYXJpbHkgbWVhbiAibmV0d29yayBpZGVudGlmaWVyIj8gSXQgc2VlbXMgDQo+PiB0byBt ZSB0aGF0IGl0IGlzIHVzZWZ1bCB0byBoYXZlIGEgdW5pcXVlIGxvbmctdGVybSBpZGVudGlmaWVy IGZvciANCj4+IGV2ZXJ5IGRldmljZSwgYmFzZWQgb24gaXRzIHB1YmxpYyBrZXkuIFdoZXRoZXIg eW91IGNhbiBvYnRhaW4gYSANCj4+IG5ldHdvcmsgY29ubmVjdGlvbiB0byB0aGF0IGRldmljZSBi YXNlZCBvbiBzdWNoIGluZm9ybWF0aW9uIGlzIGFub3RoZXIgc3RvcnkuDQo+DQo+DQo+IEl0IGlz IHVuZG91YnRlZGx5IHVzZWZ1bCB0byBoYXZlIGxvbmcgdGVybSBzdGFibGUgaWRlbnRpZmllcnMg b2YgDQo+IHZhcmlvdXMga2luZHMuIEknZCBpbmNsdWRlIGtleSBJRHMgYW5kIHB1YmxpYyBrZXlz IGFzIHN1Y2guDQo+DQo+IFR1cm5zIG91dCB0aGF0IGl0J3MgYWxzbyBmYWlybHkgdW5pdmVyc2Fs bHkgcHJpdmFjeSB1bmZyaWVuZGx5IGFzIA0KPiBwZW9wbGUgd2lsbCBhYnVzZSBzdWNoIGlkZW50 aWZpZXJzIGZvciBnb29kIGFuZCBiYWQgcmVhc29ucy4NCj4NCj4gU28gSSB0aGluayB3ZSBuZWVk IHRvIGdldCBtdWNoIGJldHRlciBhdCBhbmFseXNpbmcgd2hlbiBzdWNoIHRoaW5ncyANCj4gYXJl IHJlYWxseSBuZWVkZWQgYW5kIGluIHdoYXQgc2NvcGUuIE15IGJldCBpcyB0aGF0IGEgbG90IG9m IHRoZSB0aW1lIA0KPiBhIGxvY2FsbHkgb3IgcHJvYmFiaWxpc3RpY2FsbHkgdW5pcXVlIG1vcmUg dHJhbnNpZW50IGlkZW50aWZpZXIgd291bGQgDQo+IGJlIGp1c3QgZmluZS4NCj4NCj4gQnV0IHll YWgsIEkgY2FuJ3QgcHJvdmUgdGhhdC4gT1RPSCB0aGVyZSBpcyBhIGhpbnQgaW4gdGhlIHRlcm0g IklNU0kgDQo+IGNhdGNoZXIiIGlzbid0IHRoZXJlPw0KPg0KPiBDaGVlcnMsDQo+IFMuDQo+DQo+ Pg0KPj4gUGV0ZXINCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHBlcnBhc3MgbWFpbGluZyBsaXN0DQo+IHBlcnBhc3NAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wZXJwYXNzDQo= From nobody Wed Oct 5 17:25:14 2016 Return-Path: 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 663CA1294F5 for ; Wed, 5 Oct 2016 17:25:13 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 3-9dOY96jzxB for ; Wed, 5 Oct 2016 17:25:12 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 30E8F129404 for ; Wed, 5 Oct 2016 17:25:12 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id p102so3715635uap.0 for ; Wed, 05 Oct 2016 17:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K/elPMfO2xqfKKVbSZjPlp2y3WlxPC3t02USy4y19WM=; b=KWmpnK0/DLIP8hfGtsRhIDuUfwDG0bIbOKj9jtTuydewrYQI5UzueQm+g1NT5ztBly YEvbMl7eeGgCUBN9GvVTdDZ0q+OULiuIcNlEP3AD1+Wziq3KJ6ymBZ8NShgU1gcKTWH8 xSZB4H1Lz/ojItecLjTmOhTUhFFxPXMVk2xxJFEvtF5O9nbjvMJyYrAMI+KzKUqo1F2t ZOTRziqTVlBTi2c4MXjgzabc3rZ4fMjqeP1MpWx2LFyHgfZG1EhsWmqxpePX03vcfN1S tDpgJ4b2vjf68pG+xDjt4heUKLV1yrN7MonHRvRpdfS+/4PkwmvwCAaIIfLZbry5ealT eU1w== 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=K/elPMfO2xqfKKVbSZjPlp2y3WlxPC3t02USy4y19WM=; b=ZjkV7EN0r43GqXSjCLHan8GQuyZJMqW+TYNehFVh7XxqgXhmWQq/93ZKJ4XUhK58at Pi6KCUgWUxgMy/QLCWDOWb41Kx8S3lm9VebgjQDstwH09TMMJsWY/XP7dr0A5DCRmRvk MmnxxL506Z6Itvk5vYwjC5IUJqK/XI190u0YByJo4Pyo01s4Z+zjhNhEn1PvzSgWgMCk HNO2Q1iVx5+3K9RZnxGSI0w7W4TF93qLWFI5SgRuFg8SVcGfDYjyeJ6tJ2emMcrfGWrg Umxy8aSmhlnrc44iUz/TB4sM2EqAFDyTXV0Ws7KmDHTWOKlfFuG8RJ2sfC25o+Z06LrZ PUXQ== X-Gm-Message-State: AA6/9RlOmREkkob+aObzx24PaEx7iEVOznnZ36UH9Jz9R4kBN+Z/c1vHP0n99jzB1jRjYWTfuRHFV6mkJfv3Vg== X-Received: by 10.176.2.199 with SMTP id 65mr9016516uah.102.1475713511109; Wed, 05 Oct 2016 17:25:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.95.5 with HTTP; Wed, 5 Oct 2016 17:25:10 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:29c6:ab71:9f28:4d0a] In-Reply-To: References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: George Michaelson Date: Thu, 6 Oct 2016 10:25:10 +1000 Message-ID: To: Dave Thaler Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "perpass@ietf.org" , Peter Saint-Andre - Filament 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 00:25:13 -0000 ....And UUID generation on many devices includes a function over the MAC address, as a cheap entry to guaranteed unique bits. Such that the MAC may be randomized on the wire, but the UUID function exposed to the device may well be repurposing the baked in ID in ways which expose. From nobody Wed Oct 5 17:30:03 2016 Return-Path: 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 BC2311294F8 for ; Wed, 5 Oct 2016 17:30:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 FVi1aM66Dj1J for ; Wed, 5 Oct 2016 17:29:59 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 82A211294DD for ; Wed, 5 Oct 2016 17:29:59 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id p25so3738068uaa.1 for ; Wed, 05 Oct 2016 17:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NvHQ++397xUmroY7s6dCkpwUUPn0fSU5P758pWh9bMU=; b=EfLNi60kAl6NkVu23C5Nq4hO32vCy8r1ciWL7Ua0bWikh4mCSNhTVj0J9oo6D51iv+ 0tzFAVWfNm3W4Rw6xa6u4LS2ppuzATWB04E85GHkdI6zzQ8bKuN12oXjiB7XaWwdwfMP b+l8aI/0r7We7zfGA+QOF1gSTmHqz0cQmgX9zO8eE18rWeju1pupe7K4ADEti4HCNJhy WiQVU9ArhAT4cgftbPgkiPP2l907N4xQSOiPwu+9pzK3SQt6oWUskbgH2mgAXwhhPDE4 6xGt+Ou+mly7ptk1C1lLlyR90mceGcadCWzoKfRwhiLnlHg0YnVZePiJ2GZe547xKaHU NyGA== 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:content-transfer-encoding; bh=NvHQ++397xUmroY7s6dCkpwUUPn0fSU5P758pWh9bMU=; b=lrRV4KbsL+kPeu0pSxLEB9e19SbTodiWYzMeXz25RZUS4w+s7u3XdxRvsDDCNzrh6W WgIQgfj0scDQZruKgDAxQUfYfkBBXlE8KEIo/a3MpEKyCok+W/cCfj5Nn/HVUybZbTFv tvF/Kim16wgBwkwSkF+AZSpQqwFi/CUz8greIVTQzBCDc41KhAKSzLo9WIK6HBKp4D9G r52s/XAOogpz9gE5/Sc5/SQJy1lsuG0PLy8F1sEohsS2Qdd320PPquRYnM+ptTJlu63Y 2p+a4DFKga+pVLeu3uPTYVa8gTN56UvZjXXmEvEPlAsQcaWitXVXdNxXopsrGLdOw2fW BC4w== X-Gm-Message-State: AA6/9Rn2GJRLOeDwIO0kCjYZIqtxPnfV9vtoKrrauMNYZ+CUVm9paiyV9HaeeH3sX2MNqg4+N5D16wvPWjq+mw== X-Received: by 10.176.0.176 with SMTP id 45mr9048545uaj.90.1475713798615; Wed, 05 Oct 2016 17:29:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.95.5 with HTTP; Wed, 5 Oct 2016 17:29:57 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:29c6:ab71:9f28:4d0a] In-Reply-To: References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: George Michaelson Date: Thu, 6 Oct 2016 10:29:57 +1000 Message-ID: To: Dave Thaler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "perpass@ietf.org" , Peter Saint-Andre - Filament 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 00:30:02 -0000 btw, my primary goal was illustrative not specific. persistent ID threats are not exactly like MAC threats, but they probably lie in a similar space. I have no major concern with the desire to be deterministically both unique and known, I have this concern that the mechanisms a manufacturer can use there, tend to processes (IEEE Registry) which construct higher state (vendor-specific blocks) which have side effects. On Thu, Oct 6, 2016 at 10:09 AM, Dave Thaler wrote: > The issue with IEEE MAC's is that it's sent to untrusted observers, not t= hat 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. > > -----Original Message----- > From: George Michaelson [mailto:ggm@algebras.org] > Sent: Wednesday, October 5, 2016 5:01 PM > To: Peter Saint-Andre - Filament > Cc: perpass@ietf.org; Dave Thaler > Subject: Re: [perpass] privacy implications of UUIDs for IoT devices > > 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 identif= y probable host architecture from on-the-wire sniffs. This then leads direc= tly to: "If its a Dell, then I know the iDrac default password so I can att= empt to see if this is a badly configured Dell which has iDrac IPMI on the = host address" and like attacks. > > 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 fo= r an iPad but if you put it in your phone you are in breach of contract ove= r the use of that SIM. I am not personally a fan of this legalism, but it i= s legal, and it is an ism. > > I think there is a fundamental tension between baked in uniqueness, proba= balistic uniqueness (think ULA) and non-unique state in Layer-2 and Layer-3 > > -G > > 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 s= uch 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: core@ietf.org >> >> >> 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 >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass From nobody Wed Oct 5 17:34:26 2016 Return-Path: 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 1E3E71294F1 for ; Wed, 5 Oct 2016 17:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EaPLsreK9tMf for ; Wed, 5 Oct 2016 17:34:23 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (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 364BC1293FE for ; Wed, 5 Oct 2016 17:34:23 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id r9so194977paz.1 for ; Wed, 05 Oct 2016 17:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=wMCwRmZZwslDv0Z+TYfnhAmnLY1yhpXYB8UWDwTtVXI=; b=l3uchxK92f9ZOKZV0a7v38l3s58ZAzhu+00AyBfoO60/1ojSlK25iDWXpkUmO/q4zL MTeNFiv+4ns+kJ4REZzEjntSz7OOHQORXasykj4A0pXoqo8WrKXLQLUUbf9wzG5TcxJW qGWnW5aF6xcUVmt8PQOtQPTuUxk13p15x2KKJDrw8TfCYkOdXODJ0RtSy0n+jdjAOvSu UZEhW8owptrGnLug4Jw0wowc5miz9YGk0tChWQfHiE9a7sN1c9HHcdixpUsxn00b5AZY gls2sDRh3WEEtmFAyYPuZzT3Vcl6tofnDU06SMB4QBktDpD972ZpjMwowxTAkAGuZbFR kalA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wMCwRmZZwslDv0Z+TYfnhAmnLY1yhpXYB8UWDwTtVXI=; b=lsFIA4N2xsLAF2UBfl0e+3lcVzF2ZANz1w5NSHVvSZ10ImQE4eZg/LnYxKTxFz5DcE tLCavZud3u4Ee23AOKi3hq1aWLzkd/DPna6B9cxIZyjCcp0fD5i6Lh4OpGF/y+mBRMmJ Yf+6UEOptisQQK+lA/JGFwgtto68LxrvA3rzM+JiDlOM3TjI1Oa72m7VI5+yZtmLlVQF BDkFZGs5bpZweE7UDmxxqCWcODqt4pU3L9YSzOxLOaEWFHb2hgEbnu8/eZ6YDYR7wBde 9iF519F0owtdHFe/atP2VbUtwIcaMmOV21JcJCnZUFqZwXpbFKUoR3v2MbS4ABoHYkXb 4Thw== X-Gm-Message-State: AA6/9RllAlfK1UQDO1ber91+A3FmmuWyxakW1mF7+nzZd7YuLUoROqbaOo01s37ud65ybA== X-Received: by 10.66.5.7 with SMTP id o7mr2035839pao.19.1475714062360; Wed, 05 Oct 2016 17:34:22 -0700 (PDT) Received: from ?IPv6:2406:e007:4ce3:1:28cc:dc4c:9703:6781? ([2406:e007:4ce3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id tn5sm17170966pac.6.2016.10.05.17.34.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 17:34:21 -0700 (PDT) To: perpass@ietf.org References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8195a761-9714-df53-0c42-43bac757b203@gmail.com> Date: Thu, 6 Oct 2016 13:34:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 00:34:25 -0000 I think people need to go and read draft-ietf-netconf-zerotouch and draft-ietf-anima-bootstrapping-keyinfra. Then explain how we could ever bootstrap a trustworthy network without some sort of unique bitstring per device (in practice, an 802.1AR-2009 X.509 initial device identifier installed by the manfacturer). That doesn't mean it needs to be visible in clear after bootstrap. Regards Brian On 06/10/2016 12:54, 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: core@ietf.org > > > 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 > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > . > From nobody Wed Oct 5 18:05:14 2016 Return-Path: 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 EE0DC129404 for ; Wed, 5 Oct 2016 18:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 DyWqce5EAPIV for ; Wed, 5 Oct 2016 18:05:11 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABBE1293F5 for ; Wed, 5 Oct 2016 18:05:11 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1brx7U-0005Oo-BI for perpass@ietf.org; Thu, 06 Oct 2016 03:05:09 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1brx7R-0002GR-9Y for perpass@ietf.org; Wed, 05 Oct 2016 21:05:06 -0400 Received: (qmail 13316 invoked from network); 6 Oct 2016 01:05:04 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Oct 2016 01:05:04 -0000 From: "Christian Huitema" To: "'Brian E Carpenter'" , References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> In-Reply-To: <8195a761-9714-df53-0c42-43bac757b203@gmail.com> Date: Wed, 5 Oct 2016 18:05:02 -0700 Message-ID: <029701d21f6d$ab5e5c70$021b1550$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHrHhqZ7lEOm5Y+wD7zgEwKzfRBMgHbrl67ATmTp5egT/NcEA== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dO5jGoutCtPJ/11xS2TwWqZOY5lkjXYUoNnYIToAcyNTM4a8dHyy/6XKHITvJur9hdh9 wLVSv9mhm8xGgqvkR8k/qi69Y0KMSvcUtuRtQMKnIbtf63VNbf0lrvssY+k7AEofBVNG/3HAcYkT jK1+QSQEit8V5LMJlG7WqlxGSGzSDTQlgKl0NCglTv0GMiLlbZnckpWaLvahyBjmQxBKOzvQAufT jZZvuYhxtUmLumqmDO+ustUYaLmreOUtW3+6dDeNFeO8e/E+Ekw8fYdgTfXTPpuFqUUQz+mM8JAD 4ECWxFVfhA0wo5opwb7rzMjLtxILKgSTD/NX0ENWAOoHFGLn7qCHm7t9J44StsUNvjV8/2rAztFe klLxGNN3KHaPkHjAtYpWjlxpV9EL7OSJ3VWOecfSiNGtWyX+SkzL/xDONGP0PwcsocAqk8Y/wQ+e 4Bn8TZYUMmZkt04C8NgOiGJbXUwkuFrD1XDSUv13DQc3YXCFpq8YnEJMb3PcNAkxC60jiD6XqsJZ tjQxlyCdsewTaGJorwW9JJ/gTcx95t8bMiBnidwi6OkAXzU5a6Q/tJTbLDrPzkvdTIJ076hDdLsR ZMxd0ZLZrOPTv3nlZv/9 X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.56) X-Recommended-Action: accept Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 01:05:13 -0000 On Wednesday, October 5, 2016 5:34 PM, Brian E Carpenter wrote: > I think people need to go and read draft-ietf-netconf-zerotouch > and draft-ietf-anima-bootstrapping-keyinfra. Another useful draft is draft-winfaa-intarea-broadcast-consider. It was precisely motivated by the use of unique identifiers in device specific broadcast protocols. UUID kind of fall in that category. > Then explain how we > could ever bootstrap a trustworthy network without some sort of > unique bitstring per device (in practice, an 802.1AR-2009 X.509 > initial device identifier installed by the manfacturer). > > That doesn't mean it needs to be visible in clear after bootstrap. It also does not mean that the identifiers should be sent in clear text... -- Christian Huitema From nobody Wed Oct 5 19:44:12 2016 Return-Path: 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 ; 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 ; 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 ; 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: 6 Oct 2016 02:43:45 -0000 Message-ID: <20161006024345.20007.qmail@ary.lan> From: "John Levine" To: perpass@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 02:44:10 -0000 In article 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 From nobody Wed Oct 5 21:59:52 2016 Return-Path: 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 AA05D1294E7 for ; Wed, 5 Oct 2016 21:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.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 yDWlDeWvgIzq for ; Wed, 5 Oct 2016 21:59:48 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0049.outbound.protection.outlook.com [104.47.33.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AEB1293F5 for ; Wed, 5 Oct 2016 21:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4KMkx5HUH4s+BEOBl6UVEmcLwwDV3WV+TX1MDNMLuXI=; b=lIdyjsLIgouKIow4odvyuUC5cPoTEfCarhQR1q3aCCYzW2NqLNpbYmuwP/aOuu6Mal9akozATe/um6IKrLip4JvPpxE3m8P/Mf5bJFDj5t7+uWMDr4aFCvfM4aS3SMssTFv0JxD5axlZFzehaTerEkIP3raj/zW1GJQIVEOeVvI= Received: from SN1PR06MB1839.namprd06.prod.outlook.com (10.162.133.18) by SN1PR06MB1837.namprd06.prod.outlook.com (10.162.133.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 6 Oct 2016 04:59:46 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) by SN1PR06MB1839.namprd06.prod.outlook.com ([10.162.133.18]) with mapi id 15.01.0649.024; Thu, 6 Oct 2016 04:59:46 +0000 From: Robin Wilton To: John Levine Thread-Topic: [perpass] privacy implications of UUIDs for IoT devices Thread-Index: AQHSH2PgjkQMK9h5UkSEG8JCs3Z8j6CairuAgAACN4CAACswgIAAJgBC Date: Thu, 6 Oct 2016 04:59:46 +0000 Message-ID: <9D59C092-E692-4F27-94CD-87098BA4F767@isoc.org> References: , <20161006024345.20007.qmail@ary.lan> In-Reply-To: <20161006024345.20007.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [193.43.158.243] x-ms-office365-filtering-correlation-id: 60e33ffc-80ad-492a-037b-08d3eda597d1 x-microsoft-exchange-diagnostics: 1; SN1PR06MB1837; 6:NO/94oCvhLG55+hDh9TaQIUsDybcBns59s17x2FpdKWPQ14FRe8wX6mV9we6D9VFH+SKKI+PcpuD5AeERtSysoT0Ljv1t+Pmas5AItPpiRl/zV/qC2xFIanAWgtwMvLJl+pM+g0LsfCeMS5juYxkHG5NSHlFW/PCizxxxesWAjxp5UUrOyQTpxZLkCB801eL35Rj+I3g5jBjQTMhJXmQGi9AS4y6Kt0s35F9xQSeOe/I4RD8PpypYlCy6gDsASZrY1et3iSXvxCij3JxjfzhbZCJMwjPs/gUuMy/8E5XkyhvqdveCFKC2TI79MXe+3EW; 5:WaBoOkB38lF/YgU8/6OQh+u1u7bHtUbm/NnxMoQBuyBHR192cqbezwPC2kyOFOSFtxujW/szCaFdzLRWsQQMOg9xzpyWQNUEMal7RvRxSnJ7vb/5Om/nciWuoWGjqNxdt3j/lDVD2SHH40OroBECHHANCutltTFEoy99+SXb7n0=; 24:SuIn13+TxLKoDh6MWxmQnxS/hb84eGKAUnUCnlm/FbuxIbnqajkATfctZ0/CEFM/N0Yu7bsF4C4HClhlvAFa/UixBrq2qAOdjr+IJPIfGx4=; 7:NjeGTt2hH2qSCve8yug9yWaCUNYUeVmW+TSHrvmjvUA3wdCn8HnekHXP5J5kdSbxlwbSSmUIpI5mMh7kCZVTdPeQ5ROSWtq4fe8CUEv6Fj0cX3OZwbLu7G4CDP1F+iPPTMgGkyP+BKXoc35mJIzRXmZmq0f3y4h/4MkkYKSg3FirMuDe4NX15I5uwV+Ob1E+WPXNJo6wxhu1rEFm5Xq2F7oV+qUrjKHRj3yUPoRc32YZIsts1iu0QYivHdszeUsgWKLWXGWLYozQzjpAg1Z+hfYpMDxHQ7PlDzU1fr6aAoxczdx/Bv9kxm67CIn0Rsda x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB1837; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(218079436092871); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR06MB1837; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1837; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(24454002)(82746002)(3846002)(6116002)(102836003)(586003)(36756003)(3280700002)(5002640100001)(83716003)(19580395003)(3660700001)(87936001)(122556002)(19580405001)(106116001)(92566002)(189998001)(106356001)(68736007)(15975445007)(2900100001)(105586002)(77096005)(99286002)(97736004)(86362001)(10400500002)(305945005)(5660300001)(7736002)(8936002)(4326007)(66066001)(81166006)(81156014)(11100500001)(8676002)(7846002)(2906002)(110136003)(2950100002)(6916009)(33656002)(8666005)(50986999)(76176999)(54356999)(101416001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1837; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 04:59:46.0114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1837 Archived-At: Cc: "perpass@ietf.org" , "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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 04:59:51 -0000 On 6 Oct 2016, at 09:44, "John Levine" wrote: > In article 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. >=20 > 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. >=20 > 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. +1 ; any time you have a unique/linkable identifier that is sent without th= e user's knowledge/involvement, it undermines users' agency and therefore t= he trustworthiness of the system as a whole. Yrs., Robin >=20 > R's, > John >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Thu Oct 6 04:15:26 2016 Return-Path: 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 85AD61295F2 for ; Thu, 6 Oct 2016 04:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 5zUT3aU60RBX for ; Thu, 6 Oct 2016 04:15:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926AD1295F0 for ; Thu, 6 Oct 2016 04:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DBCC9BE47; Thu, 6 Oct 2016 12:15:20 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqByBCZskpHB; Thu, 6 Oct 2016 12:15:20 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 328B6BDF9; Thu, 6 Oct 2016 12:15:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475752520; bh=Pe7lkcAulzoEYuTCy5OJPTVIBdyF9VAzVmlYOFIkrTg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=suL29EvQFGiyJ0/oNdocR+wjxoBmTbT0FECd7tJ3QY5YWWBARdcAL07/myDVuukFc 4IyqPJ9hD/3hrgwgl7y3RmKp795Z7VYSb1HNoPKNbDHeoF7men+NFP9AKo5Nu73JQj bUQHth9Kg3maIV8GmFdNpzAVm7k/5upIqrJM9K4w= To: Peter Saint-Andre - Filament , perpass@ietf.org References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie> Date: Thu, 6 Oct 2016 12:15:20 +0100 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: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020904010401020306020501" Archived-At: Cc: Dave Thaler 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 11:15:24 -0000 This is a cryptographically signed message in MIME format. --------------ms020904010401020306020501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, 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. 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:-) Cheers, S. PS: If we had such an I-D we could figure out whether it'd be better informational, or incorporated into 3552bis or as it's own BCP, but it's premature to wonder about that until someone writes text I reckon. [1] https://tools.ietf.org/html/draft-thaler-core-redirect [2] https://tools.ietf.org/html/draft-ietf-netconf-zerotouch [3] https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra [4] https://tools.ietf.org/html/draft-winfaa-intarea-broadcast-consider On 06/10/16 00:54, 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. >=20 > 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. >=20 > 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. >=20 > Thanks! >=20 > Peter >=20 > -------- 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: core@ietf.org >=20 >=20 > Hi Peter, >=20 > 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. >=20 > It is undoubtedly useful to have long term stable identifiers of > various kinds. I'd include key IDs and public keys as such. >=20 > Turns out that it's also fairly universally privacy unfriendly > as people will abuse such identifiers for good and bad reasons. >=20 > 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. >=20 > But yeah, I can't prove that. OTOH there is a hint in the term > "IMSI catcher" isn't there? >=20 > Cheers, > S. >=20 >> >> Peter >> >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 --------------ms020904010401020306020501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDYx MTE1MjBaMC8GCSqGSIb3DQEJBDEiBCCtmozX2bDVNzGxukYWLUajv8W0tFfUUWWo1GBnzW0I QzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAqtPoI6WWYEyYzeklTv952CNOXKCoqr80XLfvBZZja4M499bG6khjn DomcB3BiQPiPFTgUUP4IW1rs5EtCG8mlMTzAPmfmTnOiNLVAL6kmkkWKoQoDIz+6VeKc+u7u peUFC1/zJS5A/t1NJ3tzJ/Dzelvvf829UdKpEO3mB0t/syPIvzODwH4Sj0ndXMkPSaCmOZQh CFySNFnUa+E31xxpVCgsRTUIP3Ac1BHkDet41tP0yRBgAbdCUr60hYguMesMknDE9rvGzuao F8e00KxiEzAdNbdanfUJ4JvnpsA+rKODTI+CPOCTlHdF0DMLoLc7TqeruCrxChMPhw8syOPP AAAAAAAA --------------ms020904010401020306020501-- From nobody Thu Oct 6 06:52:06 2016 Return-Path: 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 88AAF12965B for ; Thu, 6 Oct 2016 06:52:05 -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 wUJ5qULJdazj for ; Thu, 6 Oct 2016 06:52:01 -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 B610C129683 for ; Thu, 6 Oct 2016 06:51:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E31922009E for ; Thu, 6 Oct 2016 10:05:44 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 92C736392D for ; Thu, 6 Oct 2016 09:51:50 -0400 (EDT) From: Michael Richardson To: "perpass\@ietf.org" In-Reply-To: References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@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 Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:52:05 -0000 --=-=-= Content-Type: text/plain Dave Thaler wrote: > https://tools.ietf.org/html/draft-thaler-core-redirect-00#section-1 is > a short summary I wrote last month about this problem. okay, so it just lets one repeat the query over COAPS. With (D)TLS <=1.2, the server still reveals it's certificate identity in the ServerHello to passive observers, and while (D)TLS 1.3 "solves" this for passive observers, it doesn't help with active MITM. Or the attacker can now just initiate DTLS1.3 (but doesn't have to finish it) to find out the identity of the responding server. It seems to me that the real problem is that attackers/observers are not forced to reveal their identity first, in order that respondants can ask, "Who wants to know?" first, and also better repell DDoS. (Attackers would have to have validatable identities to even ask) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV/ZW84CLcPvd0N1lAQLp3Af/W7TbtRGWv4wBPyC4US2TRg5dEvrVHexe g0jtDtt7E4Fy65IRSjaaE23t7/c5Hs5QStewWRUR2hxaeO3q9AZZlshs8nUhcs0K bxoxsqi1xtR4fKDSMz6CqT/y78hdy3MFOAxCv+fv2F/6RSA5C1IxjD6t5Vofh3aj cb5wmVUFy4xiJQi/ZpVl1vJMSW5WY2TwVjN4Ox0TyNExVjYRo0Qph8WKb2nNJOZZ t1SP8rwKr+HY2qloODwrDi3zxwDi6kvPLsGwxdMh/2EeQpTnAM7X1S+JX7v7XBo0 NCRgstStHPPwbd2bCeEgq1yl6BcYobGWc9WbzglCC2KaGSUZ8gRDPA== =BgMT -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 6 06:54:13 2016 Return-Path: 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 E0077129664 for ; Thu, 6 Oct 2016 06:54:11 -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, 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 VC1c-Rxuz3Pl for ; Thu, 6 Oct 2016 06:54:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4235A12965B for ; Thu, 6 Oct 2016 06:54:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AE33F2009E for ; Thu, 6 Oct 2016 10:08:03 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 59E166392D for ; Thu, 6 Oct 2016 09:54:09 -0400 (EDT) From: Michael Richardson To: perpass@ietf.org In-Reply-To: <8195a761-9714-df53-0c42-43bac757b203@gmail.com> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> 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 Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:54:12 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > That doesn't mean it needs to be visible in clear after bootstrap. I'm just keeping this here to emphasis the point. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV/ZXfYCLcPvd0N1lAQLGzQf/U8xZCuG/nTgoppkySsSR+pGw6ja+ISAF ThWpBsBxGIO0lq4rWfRRt0QjoWf7evBJ/TTs3r0V3YHF6kpEMN7p7ksta3D7rS0p Y2Ebrlm1zZkR76Z2rAXh8zWNrUsINX62eu3Ti9PM7XLbCHEwlaAjnV4bbMEAR2VN deKXriJIMcf816fzLi+3o2XBhFRxIOX+1y20tjNiKLCn7DfefTZNqJ7+CDrPc55f wk9pnZGJbWto5CR2nh5ORRbQQOfKCTjIuRm8A/e6QfKxgNtCs3fdkEvmJRZEsZA3 mAwOazklrkUeELueRGTFRLfYbJvOhiXfn3qKQ0kfCM82MYSulzz+oA== =8Aw+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 6 06:58:04 2016 Return-Path: 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 DD7AA129523 for ; Thu, 6 Oct 2016 06:58:02 -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, 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 7lcWMV-SMdzz for ; Thu, 6 Oct 2016 06:58:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11C412966F for ; Thu, 6 Oct 2016 06:57:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 663EC2009E for ; Thu, 6 Oct 2016 10:11:40 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 017C76392D for ; Thu, 6 Oct 2016 09:57:46 -0400 (EDT) From: Michael Richardson To: perpass@ietf.org In-Reply-To: <029701d21f6d$ab5e5c70$021b1550$@huitema.net> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> 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 Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:58:03 -0000 --=-=-= Content-Type: text/plain Christian Huitema wrote: >> I think people need to go and read draft-ietf-netconf-zerotouch >> and draft-ietf-anima-bootstrapping-keyinfra. > Another useful draft is draft-winfaa-intarea-broadcast-consider. It was > precisely motivated by the use of unique identifiers in device specific > broadcast protocols. UUID kind of fall in that category. >> Then explain how we >> could ever bootstrap a trustworthy network without some sort of >> unique bitstring per device (in practice, an 802.1AR-2009 X.509 >> initial device identifier installed by the manfacturer). >> >> That doesn't mean it needs to be visible in clear after bootstrap. > It also does not mean that the identifiers should be sent in clear > text... I'd love to find a way to send the identifier only to an authorized operator, which is resistant to an active MITM, given that the new device (the pledge) doesn't know who the authorized operator is yet. Encrypting it via a not-yet-fully authenticated TLS1.3 connection is easy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV/ZYV4CLcPvd0N1lAQIR4gf/STJIh79FkbeJGrtTmPN+PWgJL+QjkMbN N9G1RpZruKcYIpJ09VQgL+tP8LfJDROWr+DmB/Py6ccmErLZJibNQ1bLZtHWfFUr wWQhNMVU70c/O5sts6xbITUrgq5RvfQK4mHkjS+1wMI0W23BRf5Gze0XbZ4f92pZ NaW1RbjxxyfBJIrkTYi50GndcczYOTfL3CqAFuuu4nIIBsWdRavXxhXTYPO+K7Oc b5H2lWm9fX2PKmX24C07qhvyJ7bqDZ2tz/2V+BG7CxLW3Yj9CsD+kZnjPOGSMLoK vZMQwG3/3wGaKb/Z5SdF47epedb2Tfl5XG4p7zA6Ef5tt/EE3w+9aA== =95Cj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 6 07:03:37 2016 Return-Path: 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 4D656129677 for ; Thu, 6 Oct 2016 07:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996] 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 TgAAO8AeFHwU for ; Thu, 6 Oct 2016 07:03:34 -0700 (PDT) Received: from spamfilter1.dtu.dk (spamfilter1.dtu.dk [130.225.73.112]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4358B129676 for ; Thu, 6 Oct 2016 07:03:34 -0700 (PDT) Received: from ait-pexedg02.win.dtu.dk (ait-pexedg02.win.dtu.dk [192.38.82.192]) by spamfilter1.dtu.dk with ESMTP id u96E3Sjk006674-u96E3Sjm006674 (version=TLSv1.0 cipher=DHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 6 Oct 2016 16:03:28 +0200 Received: from ait-pex02mbx04.win.dtu.dk (192.38.82.184) by ait-pexedg02.win.dtu.dk (192.38.82.192) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Oct 2016 16:02:42 +0200 Received: from ait-pex01mbx01.win.dtu.dk ([169.254.1.231]) by ait-pex02mbx04.win.dtu.dk ([169.254.4.6]) with mapi id 14.03.0319.002; Thu, 6 Oct 2016 16:02:49 +0200 From: Hugo Maxwell Connery To: Michael Richardson , "perpass@ietf.org" Thread-Topic: [perpass] privacy implications of UUIDs for IoT devices Thread-Index: AQHSH2SCsASbqwBIZUWlsCMDuicXeqCbUUIAgAAiw0Y= Date: Thu, 6 Oct 2016 14:02:48 +0000 Message-ID: <6CB05D82CE245B4083BBF3B97E2ED470214D9AAD@ait-pex01mbx01.win.dtu.dk> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> , <29005.1475761910@obiwan.sandelman.ca> In-Reply-To: <29005.1475761910@obiwan.sandelman.ca> Accept-Language: en-AU, da-DK, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.225.73.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 14:03:36 -0000 Hi, (I was trying to not reply to this topic, but have failed.) I am very happy to see this community addressing this topic. I think it is really difficult; the implications for different actors with differing motives illuminate the challenge. 1. I want to be able to control my devices to be able to report identifiers according to my desires. 2. As a network operator, I want to be able to limit access based on a fixed identifier that the user cannot change. 1. && 2. =3D=3D False. :-( I gladly acknowledge that I am not an expert in this domain. Can we find a space that allows human freedom and supports the orderly operation of networks? What are the compromises involved in this? Can we document them and describe the different challenges for differing services? /Hugo= From nobody Thu Oct 6 07:09:37 2016 Return-Path: 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 ; 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 ; 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 ; 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 To: Stephen Farrell In-Reply-To: <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <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 Archived-At: Cc: perpass@ietf.org, Peter Saint-Andre - Filament , Dave Thaler 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 14:09:35 -0000 --=-=-= Content-Type: text/plain Stephen Farrell 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 , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV/Za/YCLcPvd0N1lAQKkdAgAumwLkxVNVvKRlsD95W5XcNo5CRDTfpQd CkWcgiZdbtB1D2kcXG9jPsb3qWye8WFPDSaw8T2QOvmWsscGsIgoPBFzVDKg4Bl5 iNTauhqstX4hZAp6tzK7yarqlxA8VW8IntGeVEhd1RmARhhuvR0eRfs1XXariNs9 Mh3qMJtBnDjeM5+om34wbt918lpV+4mCO6V+2pLtNzZ4lMHj+tqJ1wBbesVUUbFF 8ES6PgQElSZpJ/JCGl7PYrBnwqjX0RRrA4pWI/35yRUJQDhna9T64yZZNtPpil8+ 6CLV2wX1D7yo9Hr+teZX3439QP2O/CwVMP+Bo9UazRp8gzSv0bQ7jQ== =36Zc -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 6 08:54:40 2016 Return-Path: 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 E1A531296F3 for ; Thu, 6 Oct 2016 08:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 0x3dK8V_SWJz for ; Thu, 6 Oct 2016 08:54:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D421296E8 for ; Thu, 6 Oct 2016 08:54:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71D51BE4C; Thu, 6 Oct 2016 16:54:34 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMs-1xFdFilr; Thu, 6 Oct 2016 16:54:34 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CA8FABE47; Thu, 6 Oct 2016 16:54:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1475769274; bh=X8gdFcFc7Qb0PNk8CkHAdVjAJtP9kCr12aX3OWFpUq0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=MGKxj/G0ORpWxqGVPAjpN2ci9mpyfRqdwp1Rt9BMnHR439pQquiVy+UcAJ927Y3hc GBzguLwxn7qEBxwKSTeXbKHfF6fYiY3bs322m/dpEyok9IOrvgfHspw9ZjpmDvHtZS v/XPaxa41AGsgHyduwLZUxrYx6/AtPv+T1lrVj/k= To: Michael Richardson References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie> <32752.1475762946@obiwan.sandelman.ca> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 6 Oct 2016 16:54:32 +0100 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: <32752.1475762946@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oSxp2oo7moOvGB2Isf82m0v4jAr5GhU0X" Archived-At: Cc: perpass@ietf.org, Peter Saint-Andre - Filament , Dave Thaler 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 15:54:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oSxp2oo7moOvGB2Isf82m0v4jAr5GhU0X Content-Type: multipart/mixed; boundary="61xi5rv6d06eM8nUNt00ghmCFPpxPS6St"; protected-headers="v1" From: Stephen Farrell To: Michael Richardson Cc: Peter Saint-Andre - Filament , perpass@ietf.org, Dave Thaler Message-ID: Subject: Re: [perpass] privacy implications of UUIDs for IoT devices References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie> <32752.1475762946@obiwan.sandelman.ca> In-Reply-To: <32752.1475762946@obiwan.sandelman.ca> --61xi5rv6d06eM8nUNt00ghmCFPpxPS6St Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/10/16 15:09, Michael Richardson wrote: > I will volunteer, and I'll do this publically so that you'll hold me to= it. > Expect it by draft cut-off date. >=20 Excellent, thanks! S. --61xi5rv6d06eM8nUNt00ghmCFPpxPS6St-- --oSxp2oo7moOvGB2Isf82m0v4jAr5GhU0X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX9nO5AAoJEC88hzaAX42i4cEH/1xJZmL5fiv8/KgJn/SY0I8N YapTDmacCBMwMSwH04C030xUryeI+mnjAUrYzR/RgvV2O2WEKXwfK4p+51KA+yZm vnEUrKdMwFNnPZDWsh1dU4RitZliXQ+m+3kTgS3OKmgFPzCBZWCe21la5k9Qfams zIeD4UPZfZxwSNV6js+RSjzcCw70+7OIri1ff3oXrl0uQf8NMu83Asazzq9kwd0q PigXyiC9LjBpVxs6w8A9Mmht+AjVeLgaUKGohYoCr3dAKAc750Us5y0y/u8GaXpk p0p+e//zwA27qegUXAd2P0YQqdTKdCyOD88NWMI5exCOkN7dLeupVO5l/fmNEHc= =s/cp -----END PGP SIGNATURE----- --oSxp2oo7moOvGB2Isf82m0v4jAr5GhU0X-- From nobody Thu Oct 6 18:41:34 2016 Return-Path: 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 163611294EB for ; Thu, 6 Oct 2016 18:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 MnoU2J8V29Lu for ; Thu, 6 Oct 2016 18:41:31 -0700 (PDT) Received: from mx36.antispamcloud.com (mx36.antispamcloud.com [209.126.110.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156B31294E0 for ; Thu, 6 Oct 2016 18:41:31 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bsKAD-0004Na-5T for perpass@ietf.org; Fri, 07 Oct 2016 03:41:30 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bsKA8-0006lh-9F for perpass@ietf.org; Thu, 06 Oct 2016 21:41:28 -0400 Received: (qmail 3886 invoked from network); 7 Oct 2016 01:41:22 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Oct 2016 01:41:22 -0000 From: "Christian Huitema" To: "'Michael Richardson'" , References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> <30295.1475762265@obiwan.sandelman.ca> In-Reply-To: <30295.1475762265@obiwan.sandelman.ca> Date: Thu, 6 Oct 2016 18:41:19 -0700 Message-ID: <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHrHhqZ7lEOm5Y+wD7zgEwKzfRBMgHbrl67ATmTp5cB1jgsIAGVQjBPoDYwOmA= Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dO5jGoutCtPJ/11xS2TwWqZOY5lkjXYUoNnYIToAcyNTM4a8dHyy/6XKHITvJur9hRz1 vmbBNUUUF7OGYQGT1IVlIWMRY2xck75ZvJYfOV+AIbtf63VNbf0lrvssY+k7AEofBVNG/3HAcYkT jK1+QSSGn8wPJlm+mlWte+eW4PFQDTQlgKl0NCglTv0GMiLlbZnckpWaLvahyBjmQxBKOzvQAufT jZZvuYhxtUmLumqmDO+ustUYaLmreOUtW3+6dP/uW8cjfZKDJxNnAu8C6KzTPpuFqUUQz+mM8JAD 4ECWhYQP/mptVJ90x8M9sDf57hILKgSTD/NX0ENWAOoHFGLn7qCHm7t9J44StsUNvjV8/2rAztFe klLxGNN3KHaPkHjAtYpWjlxpV9EL7OSJ3VWOecfSiNGtWyX+SkzL/xDONGP0PwcsocAqk8Y/wQ+e 4Bn8TZYUMmZkt04C8NgOiGIE2zQ4G9/6t2mVlEiJsf0WYXCFpq8YnEJMb3PcNAkxC60jiD6XqsJZ tjQxlyCdsezipi5yDiig4uL/e3hw9DLyM+540POWImOXNQcRyCdG97cH6r5tQdcCxgWCw1EQaGW+ wt1wLYdmK1XFwa0D0D4g X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.43) X-Recommended-Action: accept Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 01:41:33 -0000 On Thursday, October 6, 2016 6:58 AM, Michael Richardson wrote: > > ... > I'd love to find a way to send the identifier only to an authorized operator, > which is resistant to an active MITM, given that the new device (the pledge) > doesn't know who the authorized operator is yet. We are looking at that in the pairing draft in DNSSD (https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The hypothesis is that the two paired devices can display a short authentication string, e.g. 6-7 digits. Given that, we can establish a TLS connection without prior credentials between the two parties, with a probability 99.9999% that any MITM attempt will be detected. But the two parties have to be able to "see" the string display on the other device and compare it to the local one. ZRTP uses the same algorithm to detect MITM in audio connection, probably assuming that the parties will read the string over the audio channel and that the MITM cannot really rework the audio in real time. There is another trick, used in the privacy extensions to DNS-SD (https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). Use TLS PSK, or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that can only be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK). That guarantees connection without MITM, and also without disclosure of the identities to third parties. Problem, it scales as O(number of PSK) known by the server. We could probably devse an extension of that using public key technology. -- Christian Huitema From nobody Fri Oct 7 06:49:03 2016 Return-Path: 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 0AF93129464 for ; Fri, 7 Oct 2016 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 HDiBRHwAKTTY for ; Fri, 7 Oct 2016 06:48:59 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 D1D011295E3 for ; Fri, 7 Oct 2016 06:48:58 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id u68so45303448uau.2 for ; Fri, 07 Oct 2016 06:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZuNTC6FO9c9hjaBXbYRATmxeQ6d1YvKR2PvUEycg2kk=; b=YX+u0Ca6m2UvgTnXfpmNRXTgUAdg4TPSvgaiI7cjrUakvl42e860kRo6AyLhOCxHg3 knV4ySHVnWEbwUUwGL6S8HjK0iL4DrmldN8TvS2JIv1nEqsV5F7D6EFFQk5WvEx5Fap0 q4MYaBEih8TKcAG8FNIgKRao/x/uDUkAPZ710= 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=ZuNTC6FO9c9hjaBXbYRATmxeQ6d1YvKR2PvUEycg2kk=; b=XpWMk9xOmSYmtgOvLw3Wbm2qUSvd5HoftMiEE7o+iZOCfq/ddBJQ0qPbO/E9AIQeZa AtCYDt3rDfLUk9MuqSQhCLuO8YK2BZ6XNhvtAt1vfEyH+R6zLZ96VOOMfxVwvA8yZNh/ zpsWLCoyFjlX+uVfddXwUX3MS+bAa1OD5Cb5wfjoVWjNFIkfUmOoAix1J9i0m4FPBhQA U3YRaSjtlh4mefQ6j5rla0EqBwaWjJ80It/tv1jj222uW2/lqA5WKZaYCAKXrHek8g6A JgD9RdajkExvrSt4VYg47H9/xcWamHP6MSuNyZkXi1Vr7Tsiqj4oiFsVUl+PmBzhtJCL RmCw== X-Gm-Message-State: AA6/9RkRZuXNAgCsVGwhJ1tYntc+WEwQ1PG55SCHEBqoq/8gArf6tAtcmto1xrkFPSVsIy/Aa05mPQA073jBKUJT X-Received: by 10.176.81.56 with SMTP id e53mr15115003uaa.160.1475848137899; Fri, 07 Oct 2016 06:48:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.33.208 with HTTP; Fri, 7 Oct 2016 06:48:37 -0700 (PDT) In-Reply-To: <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> <30295.1475762265@obiwan.sandelman.ca> <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> From: Joseph Lorenzo Hall Date: Fri, 7 Oct 2016 09:48:37 -0400 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=94eb2c190c540091af053e46ac5e Archived-At: Cc: Michael Richardson , perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 13:49:01 -0000 --94eb2c190c540091af053e46ac5e Content-Type: text/plain; charset=UTF-8 The Eddystone ephemeral identifier for BLE work from Google may be of interest to some here (doesn't solve cases of unknown neighbors): https://developers.google.com/beacons/eddystone-eid On Thu, Oct 6, 2016 at 9:41 PM, Christian Huitema wrote: > > On Thursday, October 6, 2016 6:58 AM, Michael Richardson wrote: > > > > ... > > I'd love to find a way to send the identifier only to an authorized > operator, > > which is resistant to an active MITM, given that the new device (the > pledge) > > doesn't know who the authorized operator is yet. > > We are looking at that in the pairing draft in DNSSD > (https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The > hypothesis > is that the two paired devices can display a short authentication string, > e.g. 6-7 digits. Given that, we can establish a TLS connection without > prior > credentials between the two parties, with a probability 99.9999% that any > MITM attempt will be detected. But the two parties have to be able to "see" > the string display on the other device and compare it to the local one. > ZRTP > uses the same algorithm to detect MITM in audio connection, probably > assuming that the parties will read the string over the audio channel and > that the MITM cannot really rework the audio in real time. > > There is another trick, used in the privacy extensions to DNS-SD > (https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). Use TLS PSK, > or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that can only > be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK). That > guarantees connection without MITM, and also without disclosure of the > identities to third parties. Problem, it scales as O(number of PSK) known > by > the server. We could probably devse an extension of that using public key > technology. > > -- Christian Huitema > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinner --94eb2c190c540091af053e46ac5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The Eddystone ephemeral identifier for BLE work from Googl= e may be of interest to some here (doesn't solve cases of unknown neigh= bors): http= s://developers.google.com/beacons/eddystone-eid

On Thu, Oct 6, 2016 at 9:41 PM,= Christian Huitema <huitema@huitema.net> wrote:

On Thursday, October 6, 2016 6:58 AM, Michael Richardson wrote:
>
> ...
> I'd love to find a way to send the identifier only to an authorize= d
operator,
> which is resistant to an active MITM, given that the new device (the pledge)
> doesn't know who the authorized operator is yet.

We are looking at that in the pairing draft in DNSSD
(https://tools.ietf.org/html/draft-ka= iser-dnssd-pairing-00). The hypothesis
is that the two paired devices can display a short authentication string, e.g. 6-7 digits. Given that, we can establish a TLS connection without prio= r
credentials between the two parties, with a probability 99.9999% that any MITM attempt will be detected. But the two parties have to be able to "= ;see"
the string display on the other device and compare it to the local one. ZRT= P
uses the same algorithm to detect MITM in audio connection, probably
assuming that the parties will read the string over the audio channel and that the MITM cannot really rework the audio in real time.

There is another trick, used in the privacy extensions to DNS-SD
(https://tools.ietf.org/html/draft-hu= itema-dnssd-privacy-02). Use TLS PSK,
or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that can only<= br> be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK). That<= br> guarantees connection without MITM, and also without disclosure of the
identities to third parties. Problem, it scales as O(number of PSK) known b= y
the server. We could probably devse an extension of that using public key technology.

-- Christian Huitema



_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass<= br>



--
Joseph Lorenzo Hall=
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST= NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 A871<= br>
Tech Prom, CDT's Annual Dinner, is April 20, 2017! https://cdt.org/annual-dinne= r
--94eb2c190c540091af053e46ac5e-- From nobody Fri Oct 7 08:10:40 2016 Return-Path: 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 07F72129641 for ; Fri, 7 Oct 2016 08:10:39 -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, 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 Xn6gwHwJGmVq for ; Fri, 7 Oct 2016 08:10:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024B2129629 for ; Fri, 7 Oct 2016 08:10:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BDAD2200A5; Fri, 7 Oct 2016 11:24:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CA5CC6392D; Fri, 7 Oct 2016 11:10:35 -0400 (EDT) From: Michael Richardson To: "Christian Huitema" In-Reply-To: <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> <30295.1475762265@obiwan.sandelman.ca> <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> 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 Content-Transfer-Encoding: quoted-printable Date: Fri, 07 Oct 2016 11:10:35 -0400 Message-ID: <7310.1475853035@obiwan.sandelman.ca> Archived-At: Cc: perpass@ietf.org 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 15:10:39 -0000 Christian Huitema wrote: >> I'd love to find a way to send the identifier only to an authorized >> operator, >> which is resistant to an active MITM, given that the new device (th= e >> pledge) >> doesn't know who the authorized operator is yet. > We are looking at that in the pairing draft in DNSSD > (https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The hyp= othesis > is that the two paired devices can display a short authentication This might be fine for larger devices with displays, but it's a fail everywhere else. Even in ANIMA, one could have a $300K BFR being deployed= , but it doesn't have a display or a person to read the display. But, does this device need privacy? But, the same system ideally bootstraps home routers, which at $39.95, sti= ll don't have a display or a competent human to read the display. > e.g. 6-7 digits. Given that, we can establish a TLS connection witho= ut prior > credentials between the two parties, with a probability 99.9999% tha= t Such as was done with the STU-III phone... > There is another trick, used in the privacy extensions to DNS-SD > (https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). Use TL= S PSK, > or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that ca= n only > be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK)= . That > guarantees connection without MITM, and also without disclosure of t= he > identities to third parties. Problem, it scales as O(number of PSK) = known by > the server. We could probably devse an extension of that using publi= c key > technology. How does the responding end know which PSK to try? I guess that's why it scales O(number of devices), because the responder h= as to try *all* of the PSK it knows? Wow. With public key technology, one could sign something, send the signature, = and let the responder try all the public keys it knows? Basically, just omit = the Certificate in the handshake. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | network architec= t [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Fri Oct 7 08:11:30 2016 Return-Path: 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 11440129641 for ; Fri, 7 Oct 2016 08:11:29 -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 gF7OIZoT1fEi for ; Fri, 7 Oct 2016 08:11:27 -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 AA4BB129635 for ; Fri, 7 Oct 2016 08:11:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 98E50200A5; Fri, 7 Oct 2016 11:25:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ACC3D6392D; Fri, 7 Oct 2016 11:11:26 -0400 (EDT) From: Michael Richardson To: Joseph Lorenzo Hall In-Reply-To: References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> <30295.1475762265@obiwan.sandelman.ca> <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> 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 Archived-At: Cc: perpass , Christian Huitema 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 15:11:29 -0000 --=-=-= Content-Type: text/plain Joseph Lorenzo Hall wrote: > The Eddystone ephemeral identifier for BLE work from Google may be of > interest to some here (doesn't solve cases of unknown neighbors): > https://developers.google.com/beacons/eddystone-eid It's a good solution for an ID once the system has been bootstrapped. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV/e7G4CLcPvd0N1lAQJESwf6AkqyljSdyqeB50TDBjNG0yToxyEd8Oie mQPzfakJl9xCuMm+L4zHkTCDZ67nnzcCIZqP/h9yYc/2cliueTIWOJ5QMcq/qjXQ KmjPM6ptNL59Sa7i7iRSVLkeB4D45U9EXObPd+oLGGO/j/DLdjrWZnAa33akd5Md 71+Ylh3REkGDkq76vpOHezq/0rNdzxtdxcVypquHobUcie1rDg/Vw1nEJRnjnfpb RkhF/aB23iLZ19nbm3HDOMWKVKnx+jt+HycVlkGodVg/MMI8xsaxADR8fKrUiqES pIp84I6Yy9pvOMx/qEUgqHByTisZappXRFKYky/9OQD2dDF+Dw7PbQ== =zpHE -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 7 10:23:05 2016 Return-Path: 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 1246B129508 for ; Fri, 7 Oct 2016 10:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 cx_IlFvvOLrZ for ; Fri, 7 Oct 2016 10:23:00 -0700 (PDT) Received: from mx36.antispamcloud.com (mx36.antispamcloud.com [209.126.110.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6362129663 for ; Fri, 7 Oct 2016 10:23:00 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bsYrK-0003FK-Vc for perpass@ietf.org; Fri, 07 Oct 2016 19:23:00 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bsYrE-000224-Uo for perpass@ietf.org; Fri, 07 Oct 2016 13:22:58 -0400 Received: (qmail 622 invoked from network); 7 Oct 2016 17:22:52 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Oct 2016 17:22:51 -0000 From: "Christian Huitema" To: "'Michael Richardson'" References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> <30295.1475762265@obiwan.sandelman.ca> <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> <7310.1475853035@obiwan.sandelman.ca> In-Reply-To: <7310.1475853035@obiwan.sandelman.ca> Date: Fri, 7 Oct 2016 10:22:49 -0700 Message-ID: <01db01d220bf$6e35d5f0$4aa181d0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHrHhqZ7lEOm5Y+wD7zgEwKzfRBMgHbrl67ATmTp5cB1jgsIAGVQjBPAiJC9OUB1YN0wqAXdHdA Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dO5jGoutCtPJ/11xS2TwWqZOY5lkjXYUoNnYIToAcyNTM4a8dHyy/6XKHITvJur9hR0p xaGJF9VJMixz6X/wphR5Jb6paMiBTPHrkfAaXZ4UIbtf63VNbf0lrvssY+k7AEofBVNG/3HAcYkT jK1+QSTg0sd5fD6p84PR7BIGp5BpDTQlgKl0NCglTv0GMiLlbZnckpWaLvahyBjmQxBKOzvQAufT jZZvuYhxtUmLumqmDO+ustUYaLmreOUtW3+6dGwRQ/sqwRqmJ6VubCWLo93TPpuFqUUQz+mM8JAD 4ECWhNUYgqtYNILWSAY+Fvn3JBILKgSTD/NX0ENWAOoHFGLn7qCHm7t9J44StsUNvjV8/2rAztFe klLxGNN3KHaPkHjAtYpWjlxpV9EL7OSJ3VWOecfSiNGtWyX+SkzL/xDONGP0PwcsocAqk8Y/wQ+e 4Bn8TZYUMmZkt04C8NgOiGIE2zQ4G9/6t2mVlEiJsf0WYXCFpq8YnEJMb3PcNAkxC60jiD6XqsJZ tjQxlyCdsezipi5yDiig4uL/e3hw9DLyM+540POWImOXNQcRyCdG97cH6r5tQdcCxgWCw1EQaGW+ wt1wLYdmK1XFwa0D0D4g X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.40) X-Recommended-Action: accept Archived-At: Cc: 'Daniel Kaiser' , perpass@ietf.org 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:23:03 -0000 On Friday, October 7, 2016 8:11 AM, Michael Richardson wrote: > Christian Huitema wrote: >>> I'd love to find a way to send the identifier only to an authorized >>> operator, >>> which is resistant to an active MITM, given that the new device (the >>> pledge) >>> doesn't know who the authorized operator is yet. > >> We are looking at that in the pairing draft in DNSSD >> (https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The hypothesis >> is that the two paired devices can display a short authentication > > This might be fine for larger devices with displays, but it's a fail > everywhere else. Even in ANIMA, one could have a $300K BFR being deployed, > but it doesn't have a display or a person to read the display. > But, does this device need privacy? > But, the same system ideally bootstraps home routers, which at $39.95, still > don't have a display or a competent human to read the display. You need some signal -- you cannot build trust out of zero knowledge and zero signal. This is not a new problem -- I am copying Daniel, who studied all that in great detail for his PhD. Over time, we have seen two solutions emerge for device pairing. Visual comparison of "short authentication strings" is arguably the best compromise between security and usability. It is widely used when the devices can display something, e.g. when pairing smart phones, tablets, PC and cars. The next most used solution is "push buttons". Push buttons at the same time on both devices, and accept the messages exchanged during that short time interval. If there is no MITM at that time, you are good, but you have no way to know that. Many other solutions have been tried. One of them is to burn some kind of key or code in one of the devices, document it on a tag, and use it on the other device to verify the exchange. It may work for big expensive devices, but it is a real pain for inexpensive devices because it introduces additional steps in the manufacturing process. Besides, it requires that the user reads and enters a long code, and that fails most usability tests. Besides that, there are solutions that attempt to use alternative channels. People have demonstrated pairing with the help of ultrasound, but that never caught. The "synchronized blinking lights" are probably the cutest solution from the literature. It is basically the same as short authentication strings, but with no display, just one LED on each device. Instead of displaying a hash on a screen, you use the hash to determine the pseudo random blinking pattern of the two lights. If they blink in unison, the user is assured that there was no MITM. Really cute, but has not quite caught on yet. As for the question whether devices need privacy, clearly it depends. My gut feeling is that mobile devices do. Portable devices, most certainly do. >> e.g. 6-7 digits. Given that, we can establish a TLS connection without prior >> credentials between the two parties, with a probability 99.9999% that > Such as was done with the STU-III phone... >> There is another trick, used in the privacy extensions to DNS-SD >> (https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). Use TLS PSK, >> or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that can only >> be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK). That >> guarantees connection without MITM, and also without disclosure of the >> identities to third parties. Problem, it scales as O(number of PSK) known by >> the server. We could probably devse an extension of that using public key >> technology. > > How does the responding end know which PSK to try? > I guess that's why it scales O(number of devices), because the responder has > to try *all* of the PSK it knows? Wow. BT-LE uses the same pattern. It works, as long as the number of PSK is not too large. In our draft, we proposed a trick to reduce the server load. Use a coarse clock as the nonce, e.g. the current time rounded to the nearest 10 minutes. This ensures that the server only has to compute the possible hash(nonce, PSK) once every 10 minutes. It also defeats the potential DOS attack in which a botnet bombs the server with connection requests and forces lots of computations. But clearly there a limits. Would probably be OK for a few hundred PSK, maybe a few thousands, but after that it breaks. > With public key technology, one could sign something, send the signature, and > let the responder try all the public keys it knows? Basically, just omit the > Certificate in the handshake. It is actually very hard to protect the servers using public key technology alone. The public key is not expected to be secret. If the attackers know the public key, they can probe for the presence of a server by attempting a connection. What might work is a combination of public key and PSK. Use the known public key of the server to encode the PSK ID, and then add a proof that the client sending the message owns the PSK. Third parties cannot deduce the client ID or the server ID from the initial message, only the server can decrypt its own public key and identify the client, and everything after that initial message will be encrypted. You do have to include a nonce in the initial message to prevent replay attacks, but it could work. -- Christian Huitema From nobody Sat Oct 8 13:24:53 2016 Return-Path: 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 AB1A1126FDC for ; Sat, 8 Oct 2016 13:24:51 -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 eEqvPVWNQIE4 for ; Sat, 8 Oct 2016 13:24:49 -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 9473B120726 for ; Sat, 8 Oct 2016 13:24:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AA82E2009E; Sat, 8 Oct 2016 16:38:50 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 641486392D; Sat, 8 Oct 2016 16:24:48 -0400 (EDT) From: Michael Richardson To: "Christian Huitema" In-Reply-To: <01db01d220bf$6e35d5f0$4aa181d0$@huitema.net> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> <30295.1475762265@obiwan.sandelman.ca> <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> <7310.1475853035@obiwan.sandelman.ca> <01db01d220bf$6e35d5f0$4aa181d0$@huitema.net> 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 Archived-At: Cc: 'Daniel Kaiser' , perpass@ietf.org 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 20:24:52 -0000 --=-=-= Content-Type: text/plain Christian Huitema wrote: >> This might be fine for larger devices with displays, but it's a fail >> everywhere else. Even in ANIMA, one could have a $300K BFR being >> deployed, >> but it doesn't have a display or a person to read the display. >> But, does this device need privacy? >> But, the same system ideally bootstraps home routers, which at $39.95, >> still >> don't have a display or a competent human to read the display. > You need some signal -- you cannot build trust out of zero knowledge and > zero signal. I agree; recall how many times semi-technicals have suggested that having source IP addresses was a privacy mistake, and we should remove them.... > This is not a new problem -- I am copying Daniel, who studied all that in > great detail for his PhD. Over time, we have seen two solutions emerge for > device pairing. Looking forward to a link to read it! > As for the question whether devices need privacy, clearly it depends. My gut > feeling is that mobile devices do. Portable devices, most certainly do. I think you are right, but there is a finer distinction to be made: 1) devices with no local identities that may need to be bootstrap'ed. 2) devices with local identities which are trying to join/use a new network. (the first time you visit CoffeeShop at corner of Fifth and Broadway) 3) devices with local identities which are re-joining a network they have been on before; but may not wish to leave a trace to a) the network operator, b) other observers. > What might work is a combination of public key and PSK. Use the known public > key of the server to encode the PSK ID, and then add a proof that the client > sending the message owns the PSK. Third parties cannot deduce the client ID > or the server ID from the initial message, only the server can decrypt its > own public key and identify the client, and everything after that initial > message will be encrypted. You do have to include a nonce in the initial > message to prevent replay attacks, but it could work. In the bootstrap or CoffeeShop situation, is the Server part of the network? In that case, how can the client know the public key of the network? How is this not vulnerable to an active MITM using a different "known public key"? This doesn't happen today with Wifi because a human either picks "CoffeeShop" ESSID, or can validate the cert chain to say "CoffeeShop Inc", but a device can't do this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV/lWDYCLcPvd0N1lAQK72Af9E1jiXJbFq/6qxZbvpLEqBBpJU6uyB/o1 GrlaEmHadORIxTFWwQQM5lDF3ZLj2o8akJe9FAFcCIAkR2+Fuu62uaQZB9J4vdo1 /L7GIthH4VGEDEGuz7tI8SeWEjzmWnD4bVpS5YzK8QOEy/ILhtZVHpi2e6QyPfOl 6YQSt5t1hOSfXS4tSjJenKYKJL+1I6p/+GiqlTIGZoCs7TuQfHQFh5WjLhctezDq 99/eFY8OydUFjIt+Z7YiwEDSEj0Pxbz6USd0WwXCQkLOHsND/oWzGp0uQjI7SFpX bIFxyhCL6z6VOx5Q8nZg6s/EWhYD5eemeMmV7aSrsp3Fu7NziGsz4g== =4tfX -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 8 17:15:09 2016 Return-Path: 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 4A44612944F for ; Sat, 8 Oct 2016 17:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eusrnt6ycg-L for ; Sat, 8 Oct 2016 17:15:05 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 42547129448 for ; Sat, 8 Oct 2016 17:15:05 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 128so19945654pfz.2 for ; Sat, 08 Oct 2016 17:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cNwCqCUvulIMcdw7lGs/Lg7ses+/L9G+YupmYloWxFY=; b=xVA3QZ9zcByeYc46qRF25QQkygTejZars7PZX8+cr99sv0NVsqUYJ3mX2pYNWBZZqy EaO0LmOYW0zno7uII1jXomfp055r3D2eDdSpJJnZ1XdDbL3iKqohRaY7c4ygk0fs8/VB jqCCZldCle1bt5GuNXwYA4OBlX7Aql8IazgI9fuFbXU4gXrbwKWj0GXOAzQvLQMg4LGK Re1fMOO2V741e7uPDQvuL4doN+9iX37cIcopDD5E8KEmzvNi/kCCCnmhvM/VZ9m+Dv/m ZqOncC9K8sxBgLSn4jIZCRs2JXpoTLEhA2u4L3POOoval6x+TewzLMeIuTmgW8hiClvK MK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cNwCqCUvulIMcdw7lGs/Lg7ses+/L9G+YupmYloWxFY=; b=G9Rnp8d66ZMtYoo+L7quvyioF8GFX1UTOuGqnhxMeaa0SkzoE7RsjErYWMY3VxOvbb c9mM8z8zNxkf7CTu7kgFMCtQmOjBhbfFfKWqM9WhJ79yGviBIRUzqKd5M6ejsq4TUSZJ CmXKqVgGVYk4oFDeFnYVBYM1fhz5vttfEP3W0uK4UroSDYWbNkNn5HjYwqSolq+8/1J/ Yu1grpO8GwwLKpZN1ZqldxvlkDQZnqRGAd72Pz5jVs0Y7zv0nbcAkkQ48gkkYWygu3Ez 7G/aINZNTPvpNptP+AbZHen482K2uU4zcNjBGkivZQUNkF5t+x4EC4TwB/ZjHI2Epp5m /Pgw== X-Gm-Message-State: AA6/9RnA4nVeVX4THJIQIb6qSosklR0+KlbIxa4o25zdUpUnO5sCSIBrEaYcjNc7QQf2Yw== X-Received: by 10.98.56.147 with SMTP id f141mr40907755pfa.83.1475972104805; Sat, 08 Oct 2016 17:15:04 -0700 (PDT) Received: from [192.168.178.23] (169.217.69.111.dynamic.snap.net.nz. [111.69.217.169]) by smtp.gmail.com with ESMTPSA id bx5sm14643021pad.6.2016.10.08.17.15.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Oct 2016 17:15:03 -0700 (PDT) To: Michael Richardson , Christian Huitema References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <8195a761-9714-df53-0c42-43bac757b203@gmail.com> <029701d21f6d$ab5e5c70$021b1550$@huitema.net> <30295.1475762265@obiwan.sandelman.ca> <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net> <7310.1475853035@obiwan.sandelman.ca> <01db01d220bf$6e35d5f0$4aa181d0$@huitema.net> <11039.1475958288@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 9 Oct 2016 00:14:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <11039.1475958288@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Daniel Kaiser' , perpass@ietf.org 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 00:15:07 -0000 On 09/10/2016 09:24, Michael Richardson wrote: > > Christian Huitema wrote: > >> This might be fine for larger devices with displays, but it's a fail > >> everywhere else. Even in ANIMA, one could have a $300K BFR being > >> deployed, > >> but it doesn't have a display or a person to read the display. > >> But, does this device need privacy? > >> But, the same system ideally bootstraps home routers, which at $39.95, > >> still > >> don't have a display or a competent human to read the display. > > > You need some signal -- you cannot build trust out of zero knowledge and > > zero signal. > > I agree; recall how many times semi-technicals have suggested that having source IP > addresses was a privacy mistake, and we should remove them.... However, encrypting the source address as part of the payload would work. This topic was in fact explored a few years ago: J. Crowcroft. SNA: Sourceless Network Architecture. In Perspectives Workshop: End-to-End Protocols for the Future Internet, Schloss Dagstuhl, 2008. www.cl.cam.ac.uk/~jac22/out/sna.pdf Brian > > > This is not a new problem -- I am copying Daniel, who studied all that in > > great detail for his PhD. Over time, we have seen two solutions emerge for > > device pairing. > > Looking forward to a link to read it! > > > As for the question whether devices need privacy, clearly it depends. My gut > > feeling is that mobile devices do. Portable devices, most certainly do. > > I think you are right, but there is a finer distinction to be made: > 1) devices with no local identities that may need to be bootstrap'ed. > > 2) devices with local identities which are trying to join/use a new network. > (the first time you visit CoffeeShop at corner of Fifth and Broadway) > > 3) devices with local identities which are re-joining a network they have > been on before; but may not wish to leave a trace to a) the network > operator, b) other observers. > > > What might work is a combination of public key and PSK. Use the known public > > key of the server to encode the PSK ID, and then add a proof that the client > > sending the message owns the PSK. Third parties cannot deduce the client ID > > or the server ID from the initial message, only the server can decrypt its > > own public key and identify the client, and everything after that initial > > message will be encrypted. You do have to include a nonce in the initial > > message to prevent replay attacks, but it could work. > > In the bootstrap or CoffeeShop situation, is the Server part of the network? > In that case, how can the client know the public key of the network? > > How is this not vulnerable to an active MITM using a different "known public key"? > This doesn't happen today with Wifi because a human either picks "CoffeeShop" > ESSID, or can validate the cert chain to say "CoffeeShop Inc", but a device > can't do this. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From nobody Fri Oct 14 03:25:54 2016 Return-Path: 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 21D921295CF for ; Fri, 14 Oct 2016 03:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no 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 ylG3vO0lH1lx for ; Fri, 14 Oct 2016 03:25:51 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88431295EE for ; Fri, 14 Oct 2016 03:25:50 -0700 (PDT) Received: from [10.56.30.17] (unknown [116.84.110.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5754681A44; Fri, 14 Oct 2016 12:25:45 +0200 (CEST) To: Peter Saint-Andre - Filament , perpass@ietf.org References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <9bdb2349-5258-27ec-493b-b5f18f61ee6a@si6networks.com> Date: Fri, 14 Oct 2016 01:12:43 -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: =?UTF-8?Q?Iv=c3=a1n_Arce?= , Dave Thaler 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 10:25:53 -0000 On 10/05/2016 08:54 PM, 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: core@ietf.org > > > 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? At the risk of sounding our own horn, draft-gont-numeric-ids-generation might be useful for guidance. For instance, our I-D essentially argues that you should be asking yourself the question: "what are the interoperability properties you need for such IDs?". Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Oct 14 03:26:00 2016 Return-Path: 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 39FEF1296F0 for ; Fri, 14 Oct 2016 03:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no 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 C5Co_ZXhnXyN for ; Fri, 14 Oct 2016 03:25:57 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC131296F2 for ; Fri, 14 Oct 2016 03:25:57 -0700 (PDT) Received: from [10.56.30.17] (unknown [116.84.110.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1A19681A4A; Fri, 14 Oct 2016 12:25:52 +0200 (CEST) To: George Michaelson , Peter Saint-Andre - Filament References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: Fernando Gont Message-ID: Date: Fri, 14 Oct 2016 01:20:13 -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: "perpass@ietf.org" , Dave Thaler 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 10:25:58 -0000 On 10/05/2016 09:01 PM, George Michaelson wrote: > 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 > attacks. > > 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 Please see: draft-gont-numeric-ids-generation-01 Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Oct 14 03:26:26 2016 Return-Path: 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 ED86D1295CF for ; Fri, 14 Oct 2016 03:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 nogRabDm1bYm for ; Fri, 14 Oct 2016 03:26:24 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1381296FE for ; Fri, 14 Oct 2016 03:26:11 -0700 (PDT) Received: from [10.56.30.17] (unknown [116.84.110.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DCD0681A44; Fri, 14 Oct 2016 12:26:07 +0200 (CEST) To: Stephen Farrell , Peter Saint-Andre - Filament , perpass@ietf.org References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie> From: Fernando Gont Message-ID: <62d7fc10-44c4-4625-54e2-6837cac5004f@si6networks.com> Date: Fri, 14 Oct 2016 01:28:35 -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: <12e330d2-1097-7fba-1a9c-514e536878b0@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Dave Thaler 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 10:26:25 -0000 On 10/06/2016 08:15 AM, Stephen Farrell wrote: > Hiya, > > 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. > > 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:-) That's what we've tried to do in: draft-gont-numeric-ids-generation-01 Input welcome! Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Oct 14 03:26:30 2016 Return-Path: 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 0BCDF129703 for ; Fri, 14 Oct 2016 03:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB1F3cme54My for ; Fri, 14 Oct 2016 03:26:17 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761B01296FD for ; Fri, 14 Oct 2016 03:26:05 -0700 (PDT) Received: from [10.56.30.17] (unknown [116.84.110.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 01F1681A44; Fri, 14 Oct 2016 12:25:59 +0200 (CEST) To: Dave Thaler , George Michaelson , Peter Saint-Andre - Filament References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> 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: "perpass@ietf.org" 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. " 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... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Oct 14 04:15:32 2016 Return-Path: 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 ; 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 ; 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 ; Fri, 14 Oct 2016 04:15:28 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id s49so69810961qta.0 for ; 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> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> From: Eitan Adler Date: Fri, 14 Oct 2016 04:14:56 -0700 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "perpass@ietf.org" , Peter Saint-Andre - Filament , George Michaelson , Dave Thaler 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 11:15:30 -0000 On 13 October 2016 at 21:23, Fernando Gont 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 From nobody Fri Oct 14 07:55:37 2016 Return-Path: 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 DFEE4129415 for ; Fri, 14 Oct 2016 07:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 LCxiafXnMS2t for ; Fri, 14 Oct 2016 07:55:34 -0700 (PDT) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id AD0F31295C2 for ; Fri, 14 Oct 2016 07:55:16 -0700 (PDT) X-AuditID: 1207440e-c7bff70000000b1c-94-5800f1d28d03 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 75.8E.02844.2D1F0085; Fri, 14 Oct 2016 10:55:15 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u9EEtE1E012123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 14 Oct 2016 10:55:14 -0400 To: perpass@ietf.org References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> From: Paul Kyzivat Message-ID: Date: Fri, 14 Oct 2016 10:55:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixO6iqHvlI0OEQXecxd1LHSwOjB5Llvxk CmCM4rJJSc3JLEst0rdL4Mo4+mI/S8Fq1ormPYdZGxins3QxcnJICJhItLS1sHcxcnEICVxm lFh1/w0ThPOOSWLjhk3MIFXCAi4St25MYAWxRQREJBatesYKUXSUSWLyyZ2MIAk2AS2JOYf+ g43lFbCX2Pz8PFgDi4CqxNJph8HiogJpEtvX7WaGqBGUODnzCVicU8BZ4ufKdWA2s4CtxJ25 EDXMAvIS29/OYZ7AyDcLScssJGWzkJQtYGRexSiXmFOaq5ubmJlTnJqsW5ycmJeXWqRrrJeb WaKXmlK6iRESZnw7GNvXyxxiFOBgVOLhnfGBIUKINbGsuDL3EKMkB5OSKG+tHlCILyk/pTIj sTgjvqg0J7X4EKMEB7OSCO9ikHLelMTKqtSifJiUNAeLkjiv2hJ1PyGB9MSS1OzU1ILUIpis DAeHkgSvGjCehASLUtNTK9Iyc0oQ0kwcnCDDeYCGs4DU8BYXJOYWZ6ZD5E8x6nIs+HF7LZMQ S15+XqqUOG/2e6AiAZCijNI8uDmw9PCKURzoLWHeJpA7eYCpBW7SK6AlTEBLPrSBLSlJREhJ NTCGT5q5i/fpjaT/PzP3rH2fuX71ynscab0l7hJyfY732hT6Nlaapaa0KwVOMbz9s6RLNP3R jJh/E5p+Zcb/yNSQl1o+aY8IgyqD4/z5IRqGr/k3ifybqmKZrfL58Fwjg7K0nU/jJrt2lOnM yXoY/0331rmvS4y4O/qr7rO99bxo7R3DKqA/Y6MSS3FGoqEWc1FxIgC7Nzvr6gIAAA== Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 14:55:36 -0000 On 10/14/16 12:23 AM, Fernando Gont wrote: > 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. While I understand the concern, this is also a *feature* that is widely used. When looking at devices seen on WiFi the vendor ID is often displayed and used to figure out which device is which, to correlate problem symptoms with likely causes, and many other reasons. If this "feature" were to disappear there would likely be need to invent and *overt* feature to replace it. Thanks, Paul From nobody Fri Oct 14 08:07:09 2016 Return-Path: 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 C1D52129760 for ; Fri, 14 Oct 2016 08:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 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_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 iNIbX7cPPCOt for ; Fri, 14 Oct 2016 08:07:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277DD12982B for ; Fri, 14 Oct 2016 08:07:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7B989BE2C; Fri, 14 Oct 2016 16:07:04 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUdh3hhxPPj1; Fri, 14 Oct 2016 16:07:04 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EA38FBDF9; Fri, 14 Oct 2016 16:07:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476457624; bh=gmPVX8pOzhgiN3V5DBul1vH2Ke+k/wdnoicrLaYAE0E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YTcagyNKktdW9Z51njcQAXLrJUWIlFzPcZ1uoG1MvWFTCsPeiO1MurSSsarl2QUqY Xo90aUttV1tTp+6eNhF9h9+59AOhOjPLuHHbUxVd4/1qVMs2J6m3Blm6g729IbFvxI CVfMrJKfoyxYX2KTfteTIw7LDFefYRtdBICFwtJM= To: Paul Kyzivat , perpass@ietf.org References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <539e53e5-12fe-2226-f490-b7fd5b61a4d9@cs.tcd.ie> Date: Fri, 14 Oct 2016 16:07:03 +0100 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: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080009050402090808090600" Archived-At: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:07:08 -0000 This is a cryptographically signed message in MIME format. --------------ms080009050402090808090600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/10/16 15:55, Paul Kyzivat wrote: >=20 > When looking at devices seen on WiFi the vendor ID is often displayed > and used to figure out which device is which, to correlate problem > symptoms with likely causes, and many other reasons. How often? Compared to how often those are uselessly sent? (With the privacy downsides applying in all cases.) I'm not saying that the "I need to debug stuff" arguments for access to information are baseless, but I do think we (techies) to better consider the privacy implications of things like that. S. --------------ms080009050402090808090600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTQx NTA3MDNaMC8GCSqGSIb3DQEJBDEiBCBtBzyreHr5BkvaNxo1fZG86qg41Zwv9cMjNvwZ5Elt QDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCxGAvnmI0Y8MznqYDwYydsepV+/uZi452rPThhwVTjTi2sORxEHjD9 w6U5qb5JRZW7BxsjfJhctL96U/BSyeR2FI5Ww/WKj7Xfx3fOcBwLxG6aozEllZ/Q0WzjhFD6 SJDuLGTkROGTnMNCzr72pTQhKkN/hoikQrXohiiknxPzB76/ULCDziVGVvdkhdKj9ODMsF0Y ehJhnBcdlp9zIZVluwyiYZhQTDsteFIdZJT3E+YnmZx88jj4EWQuLlkPPadR1BlDiawo5g2P MEmHPJtwv7y7vA1gQTqxBvVZZU5Nz6wrsC/5fsJWSUqPltFi3RKYcLF5shZK0tNM8EstCp9v AAAAAAAA --------------ms080009050402090808090600-- From nobody Fri Oct 14 08:19:19 2016 Return-Path: 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 1CE5B129523 for ; Fri, 14 Oct 2016 08:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 qRyVbxPKrARa for ; Fri, 14 Oct 2016 08:19:13 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD3A129506 for ; Fri, 14 Oct 2016 08:19:13 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1bv4GI-0001fQ-KD for perpass@ietf.org; Fri, 14 Oct 2016 17:19:11 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bv4GC-0003Bq-6U for perpass@ietf.org; Fri, 14 Oct 2016 11:19:04 -0400 Received: (qmail 20654 invoked from network); 14 Oct 2016 15:18:59 -0000 Received: from unknown (HELO [192.168.0.111]) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Oct 2016 15:18:59 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (14A456) In-Reply-To: <539e53e5-12fe-2226-f490-b7fd5b61a4d9@cs.tcd.ie> Date: Fri, 14 Oct 2016 08:18:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C7F19FB-D521-4979-BEA7-0450AC59D8A6@huitema.net> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> <539e53e5-12fe-2226-f490-b7fd5b61a4d9@cs.tcd.ie> To: Stephen Farrell X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dO5jGoutCtPJ/11xS2TwWqZOY5lkjXYUoNnYIToAcyNTM4a8dHyy/6XKHITvJur9hbGa SnyR4uG5Qm74q4mQhHdMu7Ur8em0j+8gK+J1khYSIbtf63VNbf0lrvssY+k7AEofBVNG/3HAcYkT jK1+QSQEit8V5LMJlG7WqlxGSGzSDTQlgKl0NCglTv0GMiLlbZnckpWaLvahyBjmQxBKOzvQAufT jZZvuYhxtUmLumqmDO+ustUYaLmreOUtW3+6dDeNFeO8e/E+Ekw8fYdgTfXTPpuFqUUQz+mM8JAD 4ECWxFVfhA0wo5opwb7rzMjLtxILKgSTD/NX0ENWAOoHFGLn7qCHm7t9J44StsUNvjV8/2rAztFe klLxGNN3KHaPkHjAtYpWjlxpV9EL7OSJ3VWOecfSiNGtWyX+SkzL/xDONGP0PwcsocAqk8Y/wQ+e 4Bn8TZYUMmZkt04C8NgOiGJbXUwkuFrD1XDSUv13DQc3YXCFpq8YnEJMb3PcNAkxC60jiD6XqsJZ tjQxlyCdsewTaGJorwW9JJ/gTcx95t8bMiBnidwi6OkAXzU5a6Q/tJTbLDrPzkvdTIJ076hDdLsR ZMxd0ZLZrOPTv3nlZv/9 X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept Archived-At: Cc: perpass@ietf.org, Paul Kyzivat 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:19:18 -0000 The MAC address issue is situational. When a device is moving, you want it n= ot tracked, and you want the MAC random. At home, you don't care about the d= evice privacy, and you want an easy way to do an inventory of what is on the= network. -- Christian Huitema=20 > On Oct 14, 2016, at 8:07 AM, Stephen Farrell w= rote: >=20 >=20 >=20 >> On 14/10/16 15:55, Paul Kyzivat wrote: >>=20 >> When looking at devices seen on WiFi the vendor ID is often displayed >> and used to figure out which device is which, to correlate problem >> symptoms with likely causes, and many other reasons. >=20 > How often? Compared to how often those are uselessly sent? > (With the privacy downsides applying in all cases.) >=20 > I'm not saying that the "I need to debug stuff" arguments > for access to information are baseless, but I do think we > (techies) to better consider the privacy implications of > things like that. >=20 > S. >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From ross@rbs.io Fri Oct 14 08:28:52 2016 Return-Path: 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 229CA1294CD for ; Fri, 14 Oct 2016 08:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 X3oCNdMCYPhl for ; Fri, 14 Oct 2016 08:28:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410CE129512 for ; Fri, 14 Oct 2016 08:28:43 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 874E62080C for ; Fri, 14 Oct 2016 11:28:42 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Fri, 14 Oct 2016 11:28:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=K+CnyFnPd2Mpvmi /bCigu0Au/vw=; b=g4/mg6gDRbiS6q9GmmaOgMta/HohtLiiGaJvSb5mYz8MVEb dbPSB6IETlZGOkxTEQLOQ63EXjbxzDvKQgxYIl51wfKDgtwJfnxCyNtmwRDEG81Q pRQKAiVZev/pJuy1ji0GXzlPHBYBIFfoVTShw2/Jfi4t40lnUCQjqTtgLxnI= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6537A9F553; Fri, 14 Oct 2016 11:28:42 -0400 (EDT) Message-Id: <1476458922.146295.756122441.025177B8@webmail.messagingengine.com> X-Sasl-Enc: HtLLe0z3LiVqgiCMPtYm6XIYD+bUbTTbLXCU6sHcP7Av 1476458922 From: Ross Schulman To: perpass@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-cdbff290 In-Reply-To: <8C7F19FB-D521-4979-BEA7-0450AC59D8A6@huitema.net> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> <539e53e5-12fe-2226-f490-b7fd5b61a4d9@cs.tcd.ie> <8C7F19FB-D521-4979-BEA7-0450AC59D8A6@huitema.net> Date: Fri, 14 Oct 2016 11:28:42 -0400 Archived-At: X-Mailman-Approved-At: Fri, 14 Oct 2016 08:52:33 -0700 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:30:35 -0000 In fairness, the vast majority of people have no such need "at home". I would wager that 99.9% of people who use networked devices on a daily basis have no idea what a MAC address is, would be at least somewhat concerned that that sort of consistent data was leaking from them constantly, and have no need to take an inventory of devices on a network, nor any idea how they would do that even if they wanted to. That "feature" is one that only a small portion of people (consisting of many people on this list, granted) find important and IMO is outweighed by the privacy and security implications. -Ross Schulman On Fri, Oct 14, 2016, at 11:18 AM, Christian Huitema wrote: > The MAC address issue is situational. When a device is moving, you want > it not tracked, and you want the MAC random. At home, you don't care > about the device privacy, and you want an easy way to do an inventory of > what is on the network. > > -- Christian Huitema > > > On Oct 14, 2016, at 8:07 AM, Stephen Farrell wrote: > > > > > > > >> On 14/10/16 15:55, Paul Kyzivat wrote: > >> > >> When looking at devices seen on WiFi the vendor ID is often displayed > >> and used to figure out which device is which, to correlate problem > >> symptoms with likely causes, and many other reasons. > > > > How often? Compared to how often those are uselessly sent? > > (With the privacy downsides applying in all cases.) > > > > I'm not saying that the "I need to debug stuff" arguments > > for access to information are baseless, but I do think we > > (techies) to better consider the privacy implications of > > things like that. > > > > S. > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Fri Oct 14 09:28:20 2016 Return-Path: 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 C056E12954B for ; Fri, 14 Oct 2016 09:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.onmicrosoft.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 m_hp9KCsCXBx for ; Fri, 14 Oct 2016 09:28:16 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0084.outbound.protection.outlook.com [104.47.33.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FBC129548 for ; Fri, 14 Oct 2016 09:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ls31o59CHiiuS2i8PnGzUHHIBSVlhsmqdpCkn3y87QI=; b=mWBWbJF0ekeCUUZRWru6ycXDwQSFtAB5cRaBAecXSS+DnSIox58TnQJ6PmEqLoI+wu2mlP3biyuVErDCjCy1sRqpXnpXNwddsPLOEd3EiL+npdjZkVxY74Lvup7EgURsTWiGES29nPrb/87h6g44a8JUmBTp04YKRrc+e/jU/Wk= Received: from BN6PR06MB3025.namprd06.prod.outlook.com (10.173.141.23) by BN6PR06MB3026.namprd06.prod.outlook.com (10.173.141.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Fri, 14 Oct 2016 16:28:14 +0000 Received: from BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) by BN6PR06MB3025.namprd06.prod.outlook.com ([10.173.141.23]) with mapi id 15.01.0659.020; Fri, 14 Oct 2016 16:28:14 +0000 From: Robin Wilton To: Stephen Farrell Thread-Topic: [perpass] privacy implications of UUIDs for IoT devices Thread-Index: AQHSH2PgjkQMK9h5UkSEG8JCs3Z8j6CairuAgAACN4CADNmyAIAAsIOAgAADToCAABavQA== Date: Fri, 14 Oct 2016 16:28:13 +0000 Message-ID: <6561F03D-4747-4754-A41E-73D0126E5F69@isoc.org> References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> , <539e53e5-12fe-2226-f490-b7fd5b61a4d9@cs.tcd.ie> In-Reply-To: <539e53e5-12fe-2226-f490-b7fd5b61a4d9@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [94.174.34.240] x-ms-office365-filtering-correlation-id: d37eda6a-548e-4f48-9793-08d3f44f188b x-microsoft-exchange-diagnostics: 1; BN6PR06MB3026; 6:B0VUB7/Dgz2aCXhK4OD/4LvIe5DE5PpKi4RNzI/HL4h1FPtgQiM/30RHyBGZoqoF+0iYf3QQbJlnLSAE+4uQTPPfLNA2/uDzmD4JTzrsRQ7JLS9z32nSxyCv00FCP5mbszUcT5eW/pLODSAEUz2bVz/qV9RROFtV6A/8mIgwPuNJSyBqUpTIRk3juR/jU1EmyXCPFfUxlSJD9gBSGYJsoCFbG5vK+Wmv5Zja5SVloKEliPdBMTPjtMW0QcgugL7N1hwy9ouwpUeaogZCUpSH7lAahXsSeDUs4TgyDZR1an+lWDfALdKpufDJVdbouKSe; 5:dKAHrHObVamxnhP7eu4Jj7q3XPylGv98K89iANvbuKE8B4GIZnPLBm/1JCiqFp/SNaib4Fcd/Op81AK5MyviIp2OXPCCntLaF2HyztGluC3BIwGdfD8XLNaSYo5Tgt0Gc0/v29vhpNqQTp/12KU+IQ==; 24:lPW2kR7F6lu3rWieVcxlbIghUfc+OIpDoVElNFJ7qysAxXbVweaik/g4JPPNOkEELnoXigqR0qxvT+wHNP8Kbf7iQj5a05ye02rUBmRLnbU=; 7:mL8ptshNbNPIGi85ZuliiaSZ905Tc40CYnHPOX4Dyil8oIWvp9KCHT/i+cQPr0a27sE6O+qdbAvgWNkiNg2FkILWv5fIiucmciwzOn5vz2sohXNw524DGA3kK0w79GUH4Bpa8pnZOrunpCaVEgzCxPMmDecpJxfAiSMyTjycUkyFFu9TKipyFy8/DC9hAmnxeLniu9EJazO7l5qp5UoIv/KKdgbvWfQfj9miGQRPov5i+xo9pniWcmWO9cOH0IY+efnQIT9qmqPOY+nTYroGEPcXSGpzmX2I5g/+LH510XBUxwvowQmh3TY2ZqPgosueEGhnJvd2kUokgyuNzPX9X8ofAf7ZaCTT7+BEvEZNn1Q= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR06MB3026; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN6PR06MB3026; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB3026; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(24454002)(33656002)(50986999)(92566002)(10400500002)(77096005)(3660700001)(11100500001)(3280700002)(86362001)(305945005)(5002640100001)(8676002)(68736007)(189998001)(586003)(81166006)(15975445007)(7736002)(81156014)(7846002)(8936002)(36756003)(106356001)(105586002)(106116001)(99286002)(93886004)(82746002)(5660300001)(19580405001)(19580395003)(122556002)(6916009)(101416001)(2950100002)(110136003)(3846002)(4326007)(6116002)(54356999)(102836003)(76176999)(2900100001)(66066001)(83716003)(87936001)(97736004)(2906002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3026; H:BN6PR06MB3025.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2016 16:28:13.9015 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3026 Archived-At: Cc: "perpass@ietf.org" , Paul Kyzivat 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:28:19 -0000 +1, plus a small further comment: Paul says "if this feature didn't exist, = we'd have to invent an overt equivalent" as if that's a bad thing. >From my perspective, that kind of design decision ought always to be an ove= rt one - especially where, as Stephen implies, an occasional use-case (trou= ble-shooting) is used as the justification for a permanent default with pri= vacy implications (linkable, semantically-loaded MAC address). I recommend Michelle Dennedy's book, The Privacy Engineer's Manifesto, and = Sarah Spiekermann's book on Value-based Design, for useful and informative = guidance in this area. Hope this is of use, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 14 Oct 2016, at 17:07, "Stephen Farrell" wro= te: >=20 >=20 > On 14/10/16 15:55, Paul Kyzivat wrote: >>=20 >> When looking at devices seen on WiFi the vendor ID is often displayed >> and used to figure out which device is which, to correlate problem >> symptoms with likely causes, and many other reasons. >=20 > How often? Compared to how often those are uselessly sent? > (With the privacy downsides applying in all cases.) >=20 > I'm not saying that the "I need to debug stuff" arguments > for access to information are baseless, but I do think we > (techies) to better consider the privacy implications of > things like that. >=20 > S. >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Fri Oct 14 09:48:54 2016 Return-Path: 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 E6451129516 for ; Fri, 14 Oct 2016 09:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 dDRhpYKUmWBi for ; Fri, 14 Oct 2016 09:48:51 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795AF1294E1 for ; Fri, 14 Oct 2016 09:48:51 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-09v.sys.comcast.net with SMTP id v5f8bBVYYS0FEv5f8bm21b; Fri, 14 Oct 2016 16:48:50 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-02v.sys.comcast.net with SMTP id v5f7boqvnAVHav5f7bPudH; Fri, 14 Oct 2016 16:48:50 +0000 To: Robin Wilton , Stephen Farrell References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> <539e53e5-12fe-2226-f490-b7fd5b61a4d9@cs.tcd.ie> <6561F03D-4747-4754-A41E-73D0126E5F69@isoc.org> From: Paul Kyzivat Message-ID: <183c05c2-1ea6-16b9-1ddd-3910dd79ff47@alum.mit.edu> Date: Fri, 14 Oct 2016 12:48:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6561F03D-4747-4754-A41E-73D0126E5F69@isoc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDfdplFltvCy3ZOcC6KD/+rTcgsSpirQ7ZYN+Y5QnS6TDM31+C1V4fr4GxiSMNlQShCcksXLgb0E/s4NJzJeTj8AkNMPlA1y9qnCj0+6WLjnG2J/goIz aZvIpLZ71L9kWWol1RA8k6kTPvzKHNypARF9fXXjIwjqdjlysetmRN9H0OkCZP2uwuLgf19vsA9Djt02bDJsravabqqBYBZy1F20hKWaCwKmmseuvhIrnbSo Archived-At: Cc: "perpass@ietf.org" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 16:48:53 -0000 On 10/14/16 12:28 PM, Robin Wilton wrote: > +1, plus a small further comment: Paul says "if this feature didn't exist, we'd have to invent an overt equivalent" as if that's a bad thing. > >>From my perspective, that kind of design decision ought always to be an overt one - especially where, as Stephen implies, an occasional use-case (trouble-shooting) is used as the justification for a permanent default with privacy implications (linkable, semantically-loaded MAC address). I'm ok with that. There may be a period when stuff people need to do gets harder because the new ways of doing it with privacy haven't yet been invented. Thanks, Paul > I recommend Michelle Dennedy's book, The Privacy Engineer's Manifesto, and Sarah Spiekermann's book on Value-based Design, for useful and informative guidance in this area. > > Hope this is of use, > Robin > > Robin Wilton > > Technical Outreach Director - Identity and Privacy > > On 14 Oct 2016, at 17:07, "Stephen Farrell" wrote: > >> >> >> On 14/10/16 15:55, Paul Kyzivat wrote: >>> >>> When looking at devices seen on WiFi the vendor ID is often displayed >>> and used to figure out which device is which, to correlate problem >>> symptoms with likely causes, and many other reasons. >> >> How often? Compared to how often those are uselessly sent? >> (With the privacy downsides applying in all cases.) >> >> I'm not saying that the "I need to debug stuff" arguments >> for access to information are baseless, but I do think we >> (techies) to better consider the privacy implications of >> things like that. >> >> S. >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > From nobody Fri Oct 14 15:18:37 2016 Return-Path: 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 029BB129533 for ; Fri, 14 Oct 2016 15:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 p163X26hIlCq for ; Fri, 14 Oct 2016 15:18:35 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 5219B1294C5 for ; Fri, 14 Oct 2016 15:18:35 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id rz1so50154913pab.1 for ; Fri, 14 Oct 2016 15:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Dx0EfMEkHmvAhGLAL+YPi/zoYo1KfnvPzZkKaiFf/X4=; b=YZJZ23Chw3pikOvj4dFHqsdK/esFDaDzEXZNygcdFcNy7gMOWWwfMucptyR7WmExCa o+sgZBhqJFKH8T60YQamVYIGmvlY9jkXWwv+eWo6w3XNMPTFd5ptdj1D84eWdz72chvG hNLe0us6w6fZO4KSCXl5SY/XZMJcb23fNOv3WWS2yS9mhO/p2ShrAj5ZG4uH7HMDtgGy r7ieBBG/09Erho6+gFv5IIPorZ9g+IqmsS+PrCspdWzQRVM4nLj2h3prWfPYo73+tYI/ pbayf/p5u1bC7zpRXxZmMpL4cnoCF2ci1QlTHGuPmjCKZwry1UrLfCMofZ7JsymbUrWd PyQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Dx0EfMEkHmvAhGLAL+YPi/zoYo1KfnvPzZkKaiFf/X4=; b=kL8F57oGU4d0yBpWhhZim/BxYjm51Ky+/vazy4rtmtBlkTJurqyClubyBfGqftoSfE hSMScf3hKw5q/KzQmnxAwmPpOh/zq6roigGO9mkUIO+Iw4FKdqKPJUDdcP4Qdi0Z2yGD 1tXtoM5kt/L/hHZm6uw5xeWIkWUxIwVXliVVFIHpDvhiEXXDrmRQsP2nDV/+pZEIv5+u Gw65Tn5vHvDbAh0MbCITO8hkoKeYYDTpNvJ/cry+KVzOu6A52PdYeySU5lw9PSd0VCot rBrU1XLlVn1Vk2CE1r8JWRs+ZBMLnMKzlrN0+we96Go845P/s5zbGIVG7g21izPH/tCC 0mHQ== X-Gm-Message-State: AA6/9Rmft5lNGWFFc0XTuh2/5zeEKqvAZ+YlE5s3EEJp+khpazZ+zOdF2LY6dpHr8sd2sw== X-Received: by 10.66.159.200 with SMTP id xe8mr17942024pab.21.1476483514900; Fri, 14 Oct 2016 15:18:34 -0700 (PDT) Received: from [192.168.178.23] (14.222.47.163.dynamic.snap.net.nz. [163.47.222.14]) by smtp.gmail.com with ESMTPSA id j63sm29758040pfj.70.2016.10.14.15.18.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Oct 2016 15:18:33 -0700 (PDT) To: Eitan Adler , Fernando Gont References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <61bb307c-6186-db01-1664-6ecabc9c21a3@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 15 Oct 2016 11:18:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "perpass@ietf.org" , Peter Saint-Andre - Filament , Dave Thaler , George Michaelson 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 22:18:37 -0000 On 15/10/2016 00:14, Eitan Adler wrote: > On 13 October 2016 at 21:23, Fernando Gont 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. And RFC 7217 for enterprise-like situations, RFC 7721 for general discussion of the topic, and draft-ietf-6man-default-iids which is currently with the IESG. Brian