Can we have that conversation on the DNS-SD mailing list?
The short answer to the finger printing question is that the proposed solution
addresses the fingerprinting concerns. The publicly visible information is
limited to "this unknown device publishes or use the DNS-SD privacy service."
Neither the list of services published by the device, the specific attributes
describing these services, the port numbers used by the services or the values
of the priority and weight attributes in the SRV records are visible to random
third parties. They are only accessed through the encrypted privacy discovery
service.
The reference to QR code is a bit confusing. It comes from the section
describing possible pairing solution. That section is not fully developed. In
any case, there are no QR codes involved during actual discovery. To take the
example of "two activists/journalists in Syria at a café," I would expect them
to perform the pairing beforehand at some trusted location, then perform
discovery as specified here using the privacy preserving mechanisms.
> -Original Message-
> From: Joseph Lorenzo Hall [mailto:j...@cdt.org]
> Sent: Wednesday, June 22, 2016 7:39 AM
> To: Tim Chown
> Cc: ietf-privacy@ietf.org; Ralph Droms ; Christian
> Huitema
> Subject: Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt
>
> Thanks for this. Some comments:
>
> * The last paragraph in Section 2.4 seems to be making the inevitable "what
> can
> we really do about fingerprinting?" argument. It would be great if you could
> acknowledge that despite the severe technical and practical limits on
> combatting fingerprinting, specifications should try their best to keep that
> surface area to a minimum. That may be too normative for this document?
> (Although, of course, it's clear you care about that!). As a pointer the w3c
> TAG
> had a great set of findings on unsanctioned tracking that included the
> following
> on fingerprinting:
> "because combatting fingerprinting is difficult, new Web specifications should
> take reasonable measures to avoid adding unneeded fingerprinting surface
> area. However, added surface area should not be a primary factor in
> determining whether to add a new feature."
>
> * In 4.1.1 it says, "Strictly speaking, displaying and scanning QR-codes does
> not
> establish a secure private channel, as others could also photograph this code;
> but it is reasonable secure for the application area of private service
> discovery."
> Is this not a threat model from your two more casual use cases stated in the
> document? That is, if we change the use case to two activists/journalists in
> Syria at a cafe, would you choose a different design. (For example, have the
> service generate a short random code since that will be QR-ified
> anyway.) I recognize this is just one possible option here from the document
> and that others (like WoT PKI) might be more appropriate for my Syria example.
>
>
> On Wed, Jun 22, 2016 at 8:18 AM, Tim Chown wrote:
> > Hi,
> >
> > In the dnssd WG, we are developing methods to enable scalable
> > DNS-based service discovery, which in practice means enabling
> > mDNS/DNS-SD to work over multiple links within a site. As defined,
> > mDNS/DNS-SD are link-local protocols, not forwarded by routers. If
> > successful, one ‘win’ is that users with devices can discover services
> > that may be physically near them, but that lie in a different subnet.
> >
> > At a high level, the proposed solution works by clients/resolvers
> > sending queries to hybrid proxies running on specific subnets (which
> > may be manually configured in an enterprise scenario, or
> > auto-discovered in an unmanaged home network scenario), which then
> > issue local service discovery messages, the answers to which are relayed
> > back
> to the originating querier.
> >
> > We’re encouraging discussion of privacy considerations in the WG. As a
> > result, we now have a draft (see below), including an initial proposal
> > for a solution, for which we’d welcome wider review. The draft also
> > addresses mDNS/DNS-SD privacy within single subnet scenarios.
> >
> > Feel free to comment here, or join the dnssd WG list and contribute there.
> >
> > Many thanks,
> > Tim & Ralph, dnssd WG co-chairs
> >
> > Begin forwarded message:
> >
> > From: Christian Huitema
> > Subject: [dnssd] FW: New Version Notification for
> > draft-huitema-dnssd-privacy-01.txt
> > Date: 10 June 2016 at 21:02:50 BST
> > To: "dn...@ietf.org"
> > Cc: Daniel Kaiser
> >
> > Here is a new version of the "DNS-SD Privacy" draft. I co-authored it
> > with Daniel Kaiser. Daniel is completing his PhD at the University of
> > Konstanz, in Germany, studying issues related to privacy and
> > discovery. This new draft is in my opinion much improved from the
> > version 00 that I presented in Buenos Aires. You can read the abstract
> > below for the broad lines of the proposed solution. Or, better yet, read the
> draft and comment!
>
