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

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 <alf@istumbler.net> wrote:
> 
> 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 <huitema@huitema.net> wrote:
>>> 
>>> On Thursday, March 17, 2016 4:12 PM, Tim Chown wrote:
>>> 
>>> Hi,
>>> 
>>> Ralph and I would welcome comments to the list on this draft.
>>> 
>>> Tim
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd