Subject: [dnssd] Fwd: I-D Action: draft-huitema-dnssd-privacy-00.txt

From: Tim Chown <[email-masked]>
Date: Thu, 17 Mar 2016 23:11:39 +0000

Hi,

Ralph and I would welcome comments to the list on this draft.

Tim

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-huitema-dnssd-privacy-00.txt
> Date: 10 March 2016 at 01:39:09 GMT
> To: <[email-masked]>
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Privacy Extensions for DNS-SD
>        Author          : Christian Huitema
> 	Filename        : draft-huitema-dnssd-privacy-00.txt
> 	Pages           : 12
> 	Date            : 2016-03-09
> 
> Abstract:
>   DNS-SD allows discovery of services published in DNS or MDNS.  The
>   publication normally disclose 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 a method to obfuscate the
>   identification information published by DNS-SD.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-huitema-dnssd-privacy-00
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 22 Mar 2016 21:25:43 -0700

> Ralph and I would welcome comments to the list on this draft.

Yep. Me too. This draft
(https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/) is the
continuation of the work to minimize metadata disclosure went moving to
random locations, and in particular when connecting to Wi-Fi hot spots.

The first big disclosure comes with the MAC address, and can be addressed
with MAC address randomization. The next big disclosure are the DHCP
messages, which use to disclose things like DNS name of the node, and the
DNS traffic, which would happily pass a full log of visited URL to the DNS
server chosen by the hot spot manager. The IETF has been working on that
with the DHCP anonymity profile, and with the DNS Privacy work in DPRIVE.
Which means we have to look at the next big disclosure source, which happens
to be DNS-SD.

The draft proposes essentially to obfuscate the names used in DNS-SD so that
cooperating parties understand them, but they look like gibberish to casual
observers. I am sure that DNS-SD WG members have opinions about that.

-- Christian Huitema

---

From: Alf Watt <[email-masked]>
Date: Wed, 23 Mar 2016 16:54:04 -0700

Just looking over the paper titles for DPRIV it seems like the solution is going to be TLS or DTLS of the DNS server to client connection, which should encapsulate the unicast DNS-SD as well as the usual A and AAAA lookups.

Is the concern about information disclosure from devices using DNS-SD and mDNS for multicast advertising and discovery?

Best,
Alf

> On Mar 22, 2016, at 9:25 PM, Christian Huitema <[email-masked]> wrote:
> 
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 23 Mar 2016 20:27:00 -0400

I was thinking the same thing. There won’t always be a hybrid proxy present but if there is one, it would be the perfect intermediary for unicast TLS connections to each client and service provider.

Tom

> On Mar 23, 2016, at 7:54 PM, Alf Watt <[email-masked]> wrote:
>

---

From: Alf Watt <[email-masked]>
Date: Wed, 23 Mar 2016 17:36:50 -0700

Notes after I RTFD:

For most users a single security posture or group membership won't be adequate. Some services may be private (synch with a phone, for e.g.), some shared with work mates (file and screen sharing), some with family (game and content sharing), while others are public, the service advertising stack will have to keep track of the difference and advertise and browse as appropriate.

- Yes, the concern is privacy in multicast environments, so I suggest the title change to reflect that. Strictly speaking any kind of DNS message send over mDNS is leaking information, but we only expect to see the SD, name and address resolution messages associated with DNS-SD

- 4.1: if the party is concerned they MAY use a random host name, if privacy is required they MUST

- the goal is to advertise services in such a way that hosts not implementing the updated protocol will not see them, this suggests using a new protocol and port to differentiate traffic, allow for a secure protocol design and avoid obfuscation and name mangling

- as you are proposing a shared key solution, there should be some proposal for key sharing and exchange

- this moves the solution towards Bluetooth style link-key exchange pairing model of security for local services. It's probably worth reviewing those protocols to see if one can be reused for this purpose.

- as suggested, only a single key and therefore a single 'kin' group[1] per device would be supported

- consider using a one-time key to protect the payload of an mDNS packet, and wrapping that key in one or more 'kin' group keys to allow a single service to be advertised to multiple groups:

    [mDNS message encrypted with K]
    [K encrypted with G1]
    [K encrypted with G2]
    [etc.]

- note that this allows for privately advertising the true host name and makes browsing requests private as well (only a kin will be able to unwrap the on-time-key and see the service type requested). 

Best,
Alf

[1] apologies to any former Danger Inc. employees

> On Mar 23, 2016, at 4:54 PM, Alf Watt <[email-masked]> wrote:
>

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 23 Mar 2016 22:46:16 -0700

On Wednesday, March 23, 2016 5:37 PM, Alf Watt wrote:
> ...
> For most users a single security posture or group membership won't be
> adequate. Some services may be private (synch with a phone, for e.g.),
some
> shared with work mates (file and screen sharing), some with family (game
and
> content sharing), while others are public, the service advertising stack
will
> have to keep track of the difference and advertise and browse as
appropriate.

Fair point. I am mostly concerned with the use case of several devices
roaming together, typically phone and laptop or tablet, and then of work
mates travelling together. We certainly need to work on the usage scenario
and the UI implications.

> - Yes, the concern is privacy in multicast environments, so I suggest the
title
> change to reflect that. Strictly speaking any kind of DNS message send
over
> mDNS is leaking information, but we only expect to see the SD, name and
> address resolution messages associated with DNS-SD

Multicast is certainly the first concern. I do not believe that people are
actually using server-based resolution in Wi-Fi hot spots.

> - 4.1: if the party is concerned they MAY use a random host name, if
privacy is
> required they MUST

Yes. The MAY is my awkward attempt at providing 2 ways of doing that. 

> - the goal is to advertise services in such a way that hosts not
implementing
> the updated protocol will not see them, this suggests using a new protocol
> and port to differentiate traffic, allow for a secure protocol design and
avoid
> obfuscation and name mangling

That's certainly an option. But at the same time, there is value in reusing
as much infrastructure as possible.

> - as you are proposing a shared key solution, there should be some
proposal
> for key sharing and exchange

Agreed. I wanted to have first a discussion of the concept.

> - this moves the solution towards Bluetooth style link-key exchange
pairing
> model of security for local services. It's probably worth reviewing those
> protocols to see if one can be reused for this purpose.

Bluetooth style pairing is certainly one way. I should really have added a
link to the BT LE spec, and its address obfuscation mechanism. But then,
pairing is certainly not the only way to do that. We could also use "cloud
based" mechanism, of the kind used to synchronize multiple device with the
same owner.

> - as suggested, only a single key and therefore a single 'kin' group[1]
per
> device would be supported

That would be adequate for the "laptop and phone" scenario. Not so much for
the "work mates" scenario.

> - consider using a one-time key to protect the payload of an mDNS packet,
> and wrapping that key in one or more 'kin' group keys to allow a single
> service to be advertised to multiple groups:
> 

Yes, that's the other possible design -- running encrypted MDNS on a
separate port. It is a different tradeoff. Obfuscation allows reuse of the
"low level" mechanisms, and places the burden entirely at the user
interface. Encryption makes the interface implementation easier, but
requires different ports, sending systems, etc. I believe the user-interface
solution is easier to implement and less error prone.

> - note that this allows for privately advertising the true host name and
makes
> browsing requests private as well (only a kin will be able to unwrap the
on-
> time-key and see the service type requested).

That would work, as long as the names do not leak from the "encrypted MDNS"
to the "clear text MDNS." If MDNS is configured with an obfuscated host
name, it will not leak when if an active attacker does an active search for
the clear-text name.

-- Christian Huitema

---

From: Alf Watt <[email-masked]>
Date: Sat, 26 Mar 2016 12:24:57 -0700

Christian,

Some specifics below, but generally this is something I’ve given a lot of though to and
consider an important problem to solve. It’s particularly thorny because when applied to
any use case we can conceive of today, it means having several devices on a public 
Wi-Fi network.

Unfortunately, the multicast environment in most public Wi-Fi networks is either intentionally
or unintentionally hostile. When APs and controllers for larger Wi-Fi deployments are wiling
to relay multicast frames (or any frames; along with “Disable Multicast” you will also see
“Client Isolation” enabled) between Wi-Fi clients, they often do so with least effort and 
always, by necessity, at the lowest data rate, so that everyone can reliably hear it. In busy
public hotspots many devices sending broadcast frames (including DHCP and IPv6 router
requests as well as multicast service discovery) will quickly fill up available airtime and
degrade multicast traffic.

On larger managed Wi-Fi networks we’re starting to see selective routing of multicast
messages from one broadcast domain to another via "Bonjour Gateways” and more recently
from multicast to unicast using “hybrid proxy” services, and the question of how we route
multicast traffic across a large Wi-Fi network is an open discussion (a trivial example would
be to restrict multicast service discovery traffic to a single AP, then neighboring APs). We
can expect to see the broadcast and multicast domains become more and more distinct in
deployments until they are both supplanted by some putative “Undirected Multihop over Mesh”
service discovery protocol.

Despite these present challenges and future uncertainties around multicast traffic, solving the
service discovery advertising and browsing privacy problem, in a way that reflects the way
people and groups communicate with each other and between devices, enables some
genuine improvements in networking security and user experience, starting with the use
case you propose and adding the ones which I’ve suggested to the list:

  1. Discovering obfuscated devices which have been out-of-band paired are on the local network
  2. Resolving services with assurances that the advertising entity is responding
  3. Security exchanging credentials to create device pairs or join groups
  4. Selectively advertising services to particular groups
  5. Selectively browsing services from particular groups
  6. Browsing for public services from trustworthy local hosts (with signed certs)

1) Could be implemented in existing mDNS/DNS-SD protocol stacks using new service types,
and potentially different rules on the encoding of TXT records to make their contents private,
which could all be implemented at the UI layer.

2) it should be relatively straightforward in principal to provide authenticity of mDNS responses,
insomuch as a client can be assured that the same entity which advertised a service resolved it.
Essentially; each response is signed by the same key to assure a client that they are talking to
the same entity and that the response has not been forged by using existing DNSSEC records
in the appropirate responses.

3-6) Are an expansion on the features you propose, but I think they are worthwhile to consider
as the use cases made possible by them include yours as well as some other useful ones which
I’ve already mentioned:

  - pairing of a phone and laptop for local communication
  - creation of a temporary group for:
    - trading of contact information
    - file ‘drop’ from device to device
    - game or other interactive session
   - creation of a long-term group for:
    - family services like presence and location, media sharing
    - business services like security, directory and document sharing
    - conference attendees, association members or any other organization

I think a draft laying out all the requirements and intended use cases for private, local service
discovery would help us to evaluate any proposed solutions. And we should carefully consider
the existing protocols for doing peer-to-peer discovery at proximity, across network boundaries:
besides Bluetooth, for low-bitrate PAN networks, the Wi-Fi Direct standard and Apple’s AirDrop
operate at close range and provide high bandwidth.

Both the Wi-Fi based protocols evolved in response to the multicast problems outlined above; 
two devices in proximity, even on the same Wi-Fi network in many cases, could not reliably
perform service discovery due to network policy or traffic levels, so these direct connection 
protocols developed to work around the lack of support from the network infrastructure.

Best,
Alf

> On Mar 23, 2016, at 10:46 PM, Christian Huitema <[email-masked]> wrote:
>