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

"Christian Huitema" <huitema@huitema.net> Fri, 07 October 2016 01:41 UTC

Return-Path: <huitema@huitema.net>
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 163611294EB for <perpass@ietfa.amsl.com>; Thu, 6 Oct 2016 18:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 MnoU2J8V29Lu for <perpass@ietfa.amsl.com>; Thu, 6 Oct 2016 18:41:31 -0700 (PDT)
Received: from mx36.antispamcloud.com (mx36.antispamcloud.com [209.126.110.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156B31294E0 for <perpass@ietf.org>; Thu, 6 Oct 2016 18:41:31 -0700 (PDT)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1bsKAD-0004Na-5T for perpass@ietf.org; Fri, 07 Oct 2016 03:41:30 +0200
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1bsKA8-0006lh-9F for perpass@ietf.org; Thu, 06 Oct 2016 21:41:28 -0400
Received: (qmail 3886 invoked from network); 7 Oct 2016 01:41:22 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <mcr+ietf@sandelman.ca>; 7 Oct 2016 01:41:22 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: "'Michael Richardson'" <mcr+ietf@sandelman.ca>, <perpass@ietf.org>
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>
In-Reply-To: <30295.1475762265@obiwan.sandelman.ca>
Date: Thu, 6 Oct 2016 18:41:19 -0700
Message-ID: <02aa01d2203b$e7e3a1e0$b7aae5a0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHrHhqZ7lEOm5Y+wD7zgEwKzfRBMgHbrl67ATmTp5cB1jgsIAGVQjBPoDYwOmA=
Content-Language: en-us
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dO5jGoutCtPJ/11xS2TwWqZOY5lkjXYUoNnYIToAcyNTM4a8dHyy/6XKHITvJur9hRz1 vmbBNUUUF7OGYQGT1IVlIWMRY2xck75ZvJYfOV+AIbtf63VNbf0lrvssY+k7AEofBVNG/3HAcYkT jK1+QSSGn8wPJlm+mlWte+eW4PFQDTQlgKl0NCglTv0GMiLlbZnckpWaLvahyBjmQxBKOzvQAufT jZZvuYhxtUmLumqmDO+ustUYaLmreOUtW3+6dP/uW8cjfZKDJxNnAu8C6KzTPpuFqUUQz+mM8JAD 4ECWhYQP/mptVJ90x8M9sDf57hILKgSTD/NX0ENWAOoHFGLn7qCHm7t9J44StsUNvjV8/2rAztFe klLxGNN3KHaPkHjAtYpWjlxpV9EL7OSJ3VWOecfSiNGtWyX+SkzL/xDONGP0PwcsocAqk8Y/wQ+e 4Bn8TZYUMmZkt04C8NgOiGIE2zQ4G9/6t2mVlEiJsf0WYXCFpq8YnEJMb3PcNAkxC60jiD6XqsJZ tjQxlyCdsezipi5yDiig4uL/e3hw9DLyM+540POWImOXNQcRyCdG97cH6r5tQdcCxgWCw1EQaGW+ wt1wLYdmK1XFwa0D0D4g
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.223
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.43)
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/perpass/XxjHuyAVbcxjaVWBwWMn4QUtaWw>
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: Fri, 07 Oct 2016 01:41:33 -0000

On Thursday, October 6, 2016 6:58 AM, Michael Richardson 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
(https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The hypothesis
is that the two paired devices can display a short authentication string,
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 any
MITM attempt will be detected. But the two parties have to be able to "see"
the string display on the other device and compare it to the local one. ZRTP
uses the same algorithm to detect MITM in audio connection, probably
assuming that the parties will read the string over the audio channel and
that the MITM cannot really rework the audio in real time.

There is another trick, used in the privacy extensions to DNS-SD
(https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). 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.

-- Christian Huitema