Re: [dnssd] Reviewing DNS-SD privacy issues

[Martin Thomson <[e-mail]>]

I agree with your analysis regarding granularity.  Particularly on
mobile platforms, mutual distrust between applications is the
benchmark we want to apply.  Browsers are already there.

On Sun, Dec 31, 2017 at 5:45 AM, Christian Huitema <[e-mail]> wrote:
> 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
>
>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd