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

Michael Richardson <> Sat, 08 October 2016 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB1A1126FDC for <>; Sat, 8 Oct 2016 13:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eEqvPVWNQIE4 for <>; Sat, 8 Oct 2016 13:24:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9473B120726 for <>; Sat, 8 Oct 2016 13:24:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA82E2009E; Sat, 8 Oct 2016 16:38:50 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (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$>
References: <> <> <> <029701d21f6d$ab5e5c70$021b1550$> <> <02aa01d2203b$e7e3a1e0$b7aae5a0$> <> <01db01d220bf$6e35d5f0$4aa181d0$>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 08 Oct 2016 16:24:48 -0400
Message-ID: <>
Archived-At: <>
Cc: 'Daniel Kaiser' <>,
Subject: Re: [perpass] privacy implications of UUIDs for IoT devices
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

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 <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-