[dnssd] DNSSD privacy scaling issues
Christian Huitema <huitema@huitema.net> Mon, 15 January 2018 00:55 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41EE12D854 for <dnssd@ietfa.amsl.com>; Sun, 14 Jan 2018 16:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 zGR8EKPCfJuV for <dnssd@ietfa.amsl.com>; Sun, 14 Jan 2018 16:55:38 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 A4133126DED for <dnssd@ietf.org>; Sun, 14 Jan 2018 16:55:38 -0800 (PST)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eat3o-0006jM-4Y for dnssd@ietf.org; Mon, 15 Jan 2018 01:55:37 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eat3k-0007Kl-Jy for dnssd@ietf.org; Sun, 14 Jan 2018 19:55:33 -0500
Received: (qmail 7846 invoked from network); 15 Jan 2018 00:55:31 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 15 Jan 2018 00:55:31 -0000
To: dnssd@ietf.org
From: Christian Huitema <huitema@huitema.net>
Message-ID: <dfdc831e-9ab4-6a19-ae58-ab8d55731110@huitema.net>
Date: Sun, 14 Jan 2018 14:55:27 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.230
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.70)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5myp8pHROOg/uY4IrgUSC0gXv9krsgRhBn0ayn6qsUc7oeDwbaJnZ2Ta Zhv/Bk6d8K1PdOWeIW8R8TgUu5HhPnIqBZSaVUA0RRfrX/jfaLeOTGulXfuaNr1V9B1E4+3dI5VM iIKmvXxtALVuD1NjPz5TPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31VznEK6Y0Zc8di+RlqaqtTezFdjxqs+aJ4gdrY8aSad lec4CCtvQs64a4e0Oq4D7ygHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFx6MCWuKzfg8cFFqpWFwyxcibYT4C2qF2lnc18bVJn660 xNVR/7sYVVsYFzRIpji2z/3vvjwiMlbod/y+Y0fbRzwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTDgZtJVJVWhfcbC/eCuIKr1jI1dRH6f16eQCtvwPkeoxsvP5n/w7KUFovOTT14a2Sl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/58a8lFvzsHBmOQ0AlYCXSweFFXQ>
Subject: [dnssd] DNSSD privacy scaling issues
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jan 2018 00:55:40 -0000
We want privacy. That means that the devices will "offer service to some subset of clients", rather than "offer to everybody". But we do not delegate privacy to the infrastructure, so we cannot have solutions in which the infrastructure performs access control. That leaves solution in which the service is "offered to everybody", but only qualified clients understand the "real name" behind the obfuscated name. Hence the general structure: service announces an obfuscated name, typically function of time and secret. Clients will find the available services on the network, and filter out those that they are not interested in. There are two options for the trust token: symmetric key, or asymmetric. In the symmetric version, client and server manage a shared secret. Both client and server can construct the obfuscated name. Server publishes a name, encrypt or hash of time-based nonce with shared key. Clients can also construct a priori the obfuscated names of the servers that they are interested in. Client retrieves all names and check whether some of them match the expected peer list. Or, in server based discovery, client asks server whether obfuscated name is published. The problem there is a tradeoff between scalability and impersonation. If we use the same shared secret for all clients, the protocol scales well, but any authorized client can impersonate the server for all other clients. If we use pairwise secrets, as specified in the current draft, clients cannot impersonate the server for other clients but the protocol complexity increases significantly. In the asymmetric version, client knows the public key of the server. Server constructs the obfuscated instance name by encrypting the a time-based nonce with the private key. Client looks at all available obfuscated names, and attempts to decrypt every available name. This does not scale very well - public key operation times number of keys known to client times number of services present. But... In the asymmetric version, server could also construct an obfuscated service name by encrypting a time-based nonce with the public key. Client can also construct the obfuscated service name, because it knows the public key. It can look for that name, and normally only finds one instance of the server. It can verify that this is the right server by decrypting the obfuscated name. So we get a privacy respecting discovery system in which the server publishes exactly one record, and the client typically accesses exactly one record per service/server that it discovers.
- [dnssd] DNSSD privacy scaling issues Christian Huitema
- Re: [dnssd] DNSSD privacy scaling issues Christian Huitema