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

["Christian Huitema" <[e-mail]>]

 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