Subject: [dnssd] FW: New Version Notification for draft-huitema-dnssd-privacy-01.txt

From: Christian Huitema <[email-masked]>
Date: Fri, 10 Jun 2016 20:02:50 +0000

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!

-- Christian Huitema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 10, 2016 12:35 PM
To: Christian Huitema <[email-masked]>; Daniel Kaiser <[email-masked]>
Subject: New Version Notification for draft-huitema-dnssd-privacy-01.txt

A new version of I-D, draft-huitema-dnssd-privacy-01.txt
has been successfully submitted by Christian Huitema and posted to the IETF repository.

Name:		draft-huitema-dnssd-privacy
Revision:	01
Title:		Privacy Extensions for DNS-SD
Document date:	2016-06-10
Group:		Individual Submission
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-huitema-dnssd-privacy-01.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/
Htmlized:       https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-huitema-dnssd-privacy-01

Abstract:
   DNS-SD allows discovery of services published in DNS or MDNS.  The
   publication normally discloses information about the device
   publishing the services.  There are use cases where devices want to
   communicate without disclosing their identity, for example two mobile
   devices visiting the same hotspot.

   We propose to solve this problem by a two-stage approach.  In the
   first stage, hosts discover Private Discovery Service Instances via
   DNS-SD using special formats to protect their privacy.  These service
   instances correspond to Private Discovery Servers running on peers.
   In the second stage, hosts directly query these Private Discovery
   Servers via DNS-SD over TLS.  A pairwise shared secret necessary to
   establish these connections is only known to hosts authorized by a
   pairing system.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Jun 2016 09:15:34 +0000

Hi,

Ralph and I would like to encourage some review of this updated document, particularly as it is now stepping into a proposed solution space.  

Privacy aspects are very important in all our work, and it would be great to have feedback on the updated draft in advance of the meeting in Berlin.

Many thanks,
Tim 

> On 10 Jun 2016, at 21:02, Christian Huitema <[email-masked]> wrote:
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>

---

From: Alf Watt <[email-masked]>
Date: Wed, 22 Jun 2016 15:11:01 -0700

I think the threat analysis and enumeration of privacy implication is very well done and very helpful.

The suggested mechanism for private service advertising is well thought out and an interesting method, but it’s worth mentioning two important points:

- “Pairing” (S 4.1) does solve an important security problem but I don’t think that the scope of pairing is a good fit with service discovery: which is typically between members of a group (i.e. family, workplace or school, etc) which can be larger than two people.

- An older, wiser, IETF member once pointed out to me that RFCs are not the best place to do protocol design: they are a good way to codify existing protocols so that vendors can develop interoperable implementations. In order to get these protocols implemented in real devices we need to outline the use cases and requirements for private service discovery so that vendors can consider if they want to implement them.

I’m interested in writing up those requirements, but unfortunately I’m only available volunteer hours for this work at the moment so it could take a while before I can get to it.

Best,
Alf

> On Jun 10, 2016, at 1:02 PM, Christian Huitema <[email-masked]> wrote:
>

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 23 Jun 2016 11:51:52 -0700

(Moving this conversation to DNS-SD mailing list)

On Thursday, June 23, 2016 2:53 AM, S Moonesamy wrote:
> 
> Hi Tim,
> At 05:18 22-06-2016, Tim Chown wrote:
> >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.
> 
> One of the privacy issue identified in the draft (Section 2.4) is device
> fingerprinting.  In Section 3.1, it is proposed to solve the privacy
issues
> described in Section 2.1 by obfuscating instance names.  If I had to pick
one
> privacy threat for that I would choose "correlation".  Obfuscating service
names
> would not address that.

Section 3 describes an initial design that was then abandoned. I guess that
in the next revision we could just remove that section entirely.

On the other hand, the proposal was indeed to use different obfuscated names
at different locations.

> If I understood the draft correctly, the solution "to prevent tracking
over time
> and location, different string values would be used at different
locations, or at
> different times".  QR-codes are used to generate a shared secret and
establish
> trust between two or more "friends".

The private discovery service relies on pre-existing pairings. The pairing
solutions are only drafted in very vague terms in the draft. I really wonder
whether we should go define a complete pairing protocol. Is that in-charter
for DNS-SD? What about competing with existing solutions over Bluetooth,
Wi-Fi, and certainly many more?

-- Christian Huitema