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

"Christian Huitema" <> Fri, 07 October 2016 01:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 163611294EB for <>; Thu, 6 Oct 2016 18:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MnoU2J8V29Lu for <>; Thu, 6 Oct 2016 18:41:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 156B31294E0 for <>; Thu, 6 Oct 2016 18:41:31 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <>) id 1bsKAD-0004Na-5T for; Fri, 07 Oct 2016 03:41:30 +0200
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1bsKA8-0006lh-9F for; 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) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 7 Oct 2016 01:41:22 -0000
From: "Christian Huitema" <>
To: "'Michael Richardson'" <>, <>
References: <> <> <> <029701d21f6d$ab5e5c70$021b1550$> <>
In-Reply-To: <>
Date: Thu, 6 Oct 2016 18:41:19 -0700
Message-ID: <02aa01d2203b$e7e3a1e0$b7aae5a0$>
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
Authentication-Results:; auth=pass smtp.auth=
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.43)
X-Recommended-Action: accept
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 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
> which is resistant to an active MITM, given that the new device (the
> 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 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
( 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

-- Christian Huitema