DNS-SD Privacy Scaling Tradeoffs
draft-huitema-dnssd-privacyscaling-01

Document Type Replaced Internet-Draft (dnssd WG)
Last updated 2018-09-29 (latest revision 2018-06-30)
Replaced by draft-ietf-dnssd-privacyscaling
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Adopted by a WG
Document shepherd No shepherd assigned
IESG IESG state Replaced by draft-ietf-dnssd-privacyscaling
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-huitema-dnssd-privacyscaling-01.txt

Abstract

DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. The draft currently progressing in the DNS-SD Working Group assumes peer-to-peer pairing between the service to be discovered and each of its clients. This has good security properties, but creates scaling issues, because each server needs to publish as many announcements as it has paired clients. This leads to large number of operations when servers are paired with many clients. Different designs are possible. For example, if there was only one server "discovery key" known by each authorized client, each server would only have to announce a single record, and clients would only have to process one response for each server that is present on the network. Yet, these designs will present different privacy profiles, and pose different management challenges. This draft analyses the tradeoffs between privacy and scaling in a set of different designs, using either shared secrets or public keys.

Authors

Christian Huitema (huitema@huitema.net)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)