[dnssd] Reviewing DNS-SD privacy issues

Christian Huitema <huitema@huitema.net> Sat, 30 December 2017 18:45 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 0F533126CE8 for <dnssd@ietfa.amsl.com>; Sat, 30 Dec 2017 10:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 6qUcOeeHRf3v for <dnssd@ietfa.amsl.com>; Sat, 30 Dec 2017 10:45:45 -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 B3D6A12426E for <dnssd@ietf.org>; Sat, 30 Dec 2017 10:45:45 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eVM8c-0002Qt-8C for dnssd@ietf.org; Sat, 30 Dec 2017 19:45:43 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eVM8O-0001AB-2a for dnssd@ietf.org; Sat, 30 Dec 2017 13:45:38 -0500
Received: (qmail 32191 invoked from network); 30 Dec 2017 18:45:24 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 30 Dec 2017 18:45:24 -0000
To: dnssd@ietf.org
From: Christian Huitema <huitema@huitema.net>
Message-ID: <4b8fad55-b283-e0fc-4af1-7fcfa4603193@huitema.net>
Date: Sat, 30 Dec 2017 10:45:22 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.232
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.26)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5sb7n17P+MmraK7wgxls5WMXv9krsgRhBn0ayn6qsUc7oeDwbaJnZ2Ta Zhv/Bk6d8K1PdOWeIW8R8TgUu5HhPnKi6v5Sp7DBLN/g4kkksCzlTGulXfuaNr1V9B1E4+3dI5VM iIKmvXxtALVuD1NjPz5fZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31VgwWqLoIJoKisE2LaVktjkoBooiqCtwqmCSyE26E80 CbfwQoGj+XpRrO+Kg1OI57zh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GaydQSHaKCADuB2RogJvWPZnHEeB4hpRrmo/duzUUp/Ky sNmqwxpRvH7Qpi0XSyhhmqKa8rhL3osV897Tk2bp2XLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+lXmk/kN/ohhMsDjVJmzLuIj2lB9TLiDMfXuvSrucRXqLltlcS50veJ4w4EzZsk1xpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/g25DoRJUZu4fGdJ0PkHqbW-EQhk>
Subject: [dnssd] Reviewing DNS-SD privacy 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: Sat, 30 Dec 2017 18:45:48 -0000

I have been reviewing the DNS-SD privacy issues in light of Stuart's
draft (draft-cheshire-dnssd-privacy-considerations-01) and his
presentation at IETF 100
(https://datatracker.ietf.org/meeting/100/materials/slides-100-dnssd-04-stuart-privacy/).
Draft and presentation reflect uneasiness with several of the design
choices that we made in draft-ietf-dnssd-privacy-03,
draft-ietf-dnssd-pairing-03, and draft-ietf-dnssd-pairing-info-00. I
believe this boils down to three big issues: granularity of trust, type
of secret, and type of pairing agreement.

Stuart provides a convincing illustration of the granularity issue with
the "implanted insulin monitor" example. In this example, the trust
relation is obviously between the device and the medical application on
the phone, and certainly not with "any gaming application on the phone",
let alone "any device owned by the user". Enforcing this granularity
leads to an "application-centered" design, in contrast with the
device-centered design chosen in draft-ietf-dnssd-privacy. Our two-phase
design is to "privately discover a device, then ask that device for
available services". An application centered device would be just one
phase, "privately discover an application".

There is little doubt that maintaining privacy requires some type of
trust establishment. In our drafts, we chose to base that trust on
pairwise shared secrets, established through a pairing operation.
Pairwise secrets have the advantage of being easy to understand and
manage, since the secret is shared between just two entities. But
pairwise operation scales at best as O(N), possibly O(N**2). The
alternative may be to use public key technology. This would scale better
when entities have to manage a large number of pairings, such as for
example a printer that can be used by a whole group of people, but it is
pretty hard to establish trust using public keys without disclosing at
least one of the public keys to third parties. This may be OK when one
of the parties does not have privacy concerns. For example, in the group
printer example, it may be OK to disclose the identity of the printer as
long as the identity of the users is kept private.

The pairing agreement proposed in draft-ietf-dnssd-pairing-03 relies on
a final authentication step, in which a "short authentication string" is
verified. The problem there is not the correctness of the protocol, but
the weakness of the human user. Pairing processes can be long and
convoluted. After the user has finally mastered the UI on two devices
and gone through all the process, it is very tempting to press the "OK"
button without looking too closely to the strings on the displays.
Designs that require to enter a PIN or a password before proceeding with
the pairing do not have that weakness, and technology exist that make
them secure.

These three arguments have pretty drastic consequences on the design of
"private discovery". They did surface quite late in the process, but I
agree with Stuart that the priority is to get the right standard
published. Our goal should be a standard that is widely deployed and
used. Of the three main issues above, the pairing technology is probably
the easiest to tackle -- moving from SAS to JPAKE and documenting why
would be straightforward. But the other two points deserve extended
discussion. What are the implications of moving from a device focus to
an application focus? Is this just a privacy issue, or does it affect
other aspects of DNS-SD? Can we really provide symmetric privacy with
asymmetric keys? Do we have examples of public-key based algorithms? I
would really like to see a discussion on this list!

-- Christian Huitema