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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 06 October 2016 13:52 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 88AAF12965B for <perpass@ietfa.amsl.com>; Thu, 6 Oct 2016 06:52:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 wUJ5qULJdazj for <perpass@ietfa.amsl.com>; Thu, 6 Oct 2016 06:52:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B610C129683 for <perpass@ietf.org>; Thu, 6 Oct 2016 06:51:51 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E31922009E for <perpass@ietf.org>; Thu, 6 Oct 2016 10:05:44 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 92C736392D for <perpass@ietf.org>; Thu, 6 Oct 2016 09:51:50 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "perpass@ietf.org" <perpass@ietf.org>
In-Reply-To: <CY1PR03MB2265C3482AAD1D4FD0E6829EA3C40@CY1PR03MB2265.namprd03.prod.outlook.com>
References: <5c32e81f-7e43-2bde-b8f4-46f08fecdefb@cs.tcd.ie> <db516334-43ab-e967-cfd5-87d920b65015@filament.com> <CY1PR03MB2265C3482AAD1D4FD0E6829EA3C40@CY1PR03MB2265.namprd03.prod.outlook.com>
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:51:50 -0400
Message-ID: <29005.1475761910@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/rInQQOpa2YN3ckRSd2mU8GSGtXo>
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:52:05 -0000

Dave Thaler <dthaler@microsoft.com> wrote:
    > https://tools.ietf.org/html/draft-thaler-core-redirect-00#section-1 is
    > a short summary I wrote last month about this problem.

okay, so it just lets one repeat the query over COAPS.

With (D)TLS <=1.2, the server still reveals it's certificate identity in the
ServerHello to passive observers, and while (D)TLS 1.3 "solves" this for
passive observers, it doesn't help with active MITM.

Or the attacker can now just initiate DTLS1.3 (but doesn't have to finish it)
to find out the identity of the responding server.

It seems to me that the real problem is that attackers/observers are not
forced to reveal their identity first, in order that respondants can ask,
"Who wants to know?" first, and also better repell DDoS. (Attackers would
have to have validatable identities to even ask)

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-