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>;, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>