Subject: [dnssd] Reviewing DNS-SD privacy issues

From: Christian Huitema <[email-masked]>
Date: Sat, 30 Dec 2017 10:45:22 -0800

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