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

Michael Richardson <> Fri, 07 October 2016 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07F72129641 for <>; Fri, 7 Oct 2016 08:10:39 -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, 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 Xn6gwHwJGmVq for <>; Fri, 7 Oct 2016 08:10:37 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 024B2129629 for <>; Fri, 7 Oct 2016 08:10:37 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id BDAD2200A5; Fri, 7 Oct 2016 11:24:33 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (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$>
References: <> <> <> <029701d21f6d$ab5e5c70$021b1550$> <> <02aa01d2203b$e7e3a1e0$b7aae5a0$>
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: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 07 Oct 2016 11:10:35 -0400
Message-ID: <>
Archived-At: <>
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: 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 (the
    >> pledge)
    >> doesn't know who the authorized operator is yet.

    > We are looking at that in the pairing draft in DNSSD
    > ( 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.

    > 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
    > ( 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.

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 networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [