Subject: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt

From: Tim Chown <[email-masked]>
Date: Wed, 22 Jun 2016 12:18:57 +0000

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 <[email-masked]<mailto:[email-masked]>>
Subject: [dnssd] FW: New Version Notification for draft-huitema-dnssd-privacy-01.txt
Date: 10 June 2016 at 21:02:50 BST
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Daniel Kaiser <[email-masked]<mailto:[email-masked]>>

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]> [mailto:[email-masked]]
Sent: Friday, June 10, 2016 12:35 PM
To: Christian Huitema <[email-masked]<mailto:[email-masked]>>; Daniel Kaiser <[email-masked]<mailto:[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<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
dnssd mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnssd

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 22 Jun 2016 10:39:14 -0400

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 <[email-masked]> 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.
>
> From: Christian Huitema <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Daniel Kaiser <[email-masked]>
>
> 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
>
>
>
> From: [email-masked] [mailto:[email-masked]]
> To: Christian Huitema <[email-masked]>; Daniel Kaiser
> <[email-masked]>
> URL:
> https://www.ietf.org/internet-drafts/draft-huitema-dnssd-privacy-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-huitema-dnssd-privacy-01
>
> Abstract:
> 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
>
> [email-masked]
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy
>

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Jun 2016 02:53:09 -0700

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.

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 draft identifies the problem.

Regards,
S. Moonesamy

---

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

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.

> From: Joseph Lorenzo Hall [mailto:[email-masked]]
> Sent: Wednesday, June 22, 2016 7:39 AM
> To: Tim Chown <[email-masked]>
> Cc: [email-masked]; Ralph Droms <[email-masked]>; Christian
> Huitema <[email-masked]>
> Subject: Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt
> 
> * 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
> 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.
> 
> 
> > 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.
> >
> > 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.
> >
> > 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
> >
> >
> >
> > 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: "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:
> >We're encouraging discussion of privacy considerations in the WG. As a
> >for a solution, for which we'd welcome wider review. The draft also
> 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