Re: [perpass] privacy implications of UUIDs for IoT devices
Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 09 October 2016 00:15 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 4A44612944F
for <perpass@ietfa.amsl.com>; 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 <perpass@ietfa.amsl.com>;
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 <perpass@ietf.org>; Sat, 8 Oct 2016 17:15:05 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id 128so19945654pfz.2
for <perpass@ietf.org>; 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 <mcr+ietf@sandelman.ca>,
Christian Huitema <huitema@huitema.net>
References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie>
<db516334-43ab-e967-cfd5-87d920b65015@filament.com>
<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 <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <c0b6dc1c-f69d-bbec-5636-3f74009d5f79@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/perpass/S2Lso9Z1KxXMLuhs5qEwnAVJR44>
Cc: 'Daniel Kaiser' <daniel.kaiser@uni-konstanz.de>, 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. "
<perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>,
<mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>,
<mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Oct 2016 00:15:07 -0000
On 09/10/2016 09:24, Michael Richardson wrote: > > Christian Huitema <huitema@huitema.net> 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >
- [perpass] privacy implications of UUIDs for IoT d… Peter Saint-Andre - Filament
- Re: [perpass] privacy implications of UUIDs for I… Dave Thaler
- Re: [perpass] privacy implications of UUIDs for I… George Michaelson
- Re: [perpass] privacy implications of UUIDs for I… Dave Thaler
- Re: [perpass] privacy implications of UUIDs for I… George Michaelson
- Re: [perpass] privacy implications of UUIDs for I… George Michaelson
- Re: [perpass] privacy implications of UUIDs for I… Brian E Carpenter
- Re: [perpass] privacy implications of UUIDs for I… Christian Huitema
- Re: [perpass] privacy implications of UUIDs for I… John Levine
- Re: [perpass] privacy implications of UUIDs for I… Robin Wilton
- Re: [perpass] privacy implications of UUIDs for I… Stephen Farrell
- Re: [perpass] privacy implications of UUIDs for I… Michael Richardson
- Re: [perpass] privacy implications of UUIDs for I… Michael Richardson
- Re: [perpass] privacy implications of UUIDs for I… Michael Richardson
- Re: [perpass] privacy implications of UUIDs for I… Hugo Maxwell Connery
- Re: [perpass] privacy implications of UUIDs for I… Michael Richardson
- Re: [perpass] privacy implications of UUIDs for I… Stephen Farrell
- Re: [perpass] privacy implications of UUIDs for I… Christian Huitema
- Re: [perpass] privacy implications of UUIDs for I… Joseph Lorenzo Hall
- Re: [perpass] privacy implications of UUIDs for I… Michael Richardson
- Re: [perpass] privacy implications of UUIDs for I… Michael Richardson
- Re: [perpass] privacy implications of UUIDs for I… Christian Huitema
- Re: [perpass] privacy implications of UUIDs for I… Michael Richardson
- Re: [perpass] privacy implications of UUIDs for I… Brian E Carpenter
- Re: [perpass] privacy implications of UUIDs for I… Fernando Gont
- Re: [perpass] privacy implications of UUIDs for I… Fernando Gont
- Re: [perpass] privacy implications of UUIDs for I… Fernando Gont
- Re: [perpass] privacy implications of UUIDs for I… Fernando Gont
- Re: [perpass] privacy implications of UUIDs for I… Eitan Adler
- Re: [perpass] privacy implications of UUIDs for I… Paul Kyzivat
- Re: [perpass] privacy implications of UUIDs for I… Stephen Farrell
- Re: [perpass] privacy implications of UUIDs for I… Christian Huitema
- Re: [perpass] privacy implications of UUIDs for I… Ross Schulman
- Re: [perpass] privacy implications of UUIDs for I… Robin Wilton
- Re: [perpass] privacy implications of UUIDs for I… Paul Kyzivat
- Re: [perpass] privacy implications of UUIDs for I… Brian E Carpenter