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

[Alf Watt <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:
>> 
>>    [mDNS message encrypted with K]
>>    [K encrypted with G1]
>>    [K encrypted with G2]
>>    [etc.]
> 
> 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
> 
> 
> 
> 
>