IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 06 October 2016 13:58 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 <perpass@ietfa.amsl.com>; 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 <perpass@ietfa.amsl.com>; 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 <perpass@ietf.org>; 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 <perpass@ietf.org>; 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 <perpass@ietf.org>; Thu, 6 Oct 2016 09:57:46 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: perpass@ietf.org
In-Reply-To: <029701d21f6d$ab5e5c70$021b1550$@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>
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: Thu, 06 Oct 2016 09:57:45 -0400
Message-ID: <30295.1475762265@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/FBNvqe8rRscfWNuuMHbUHaYpO2A>
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: Thu, 06 Oct 2016 13:58:03 -0000

Christian Huitema <huitema@huitema.net> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email