Subject: [dnssd] WGLC for draft-ietf-dnssd-prireq

From: David Schinazi <[email-masked]>
Date: Mon, 4 Nov 2019 14:29:56 -0800

Hi DNSSD enthusiasts,

Since there was interest in publishing the DNSSD Privacy Requirements work
at
our latest DNSSD face-to-face meeting, we're starting a Working Group Last
Call to see if we have consensus to advance the document. The working group
last call will last for 3 weeks until 2019-22-25, and we will discuss it
during the DNSSD meeting at IETF 106 in Singapore. We invite members of the
community to read the latest draft and comment on list before our in-person
meeting.

https://tools.ietf.org/html/draft-ietf-dnssd-prireq-02

Thanks,
David

---

From: Florian Adamsky <[email-masked]>
Date: Wed, 13 Nov 2019 21:02:49 +0100

Dear all,

On Monday, Nov 04 2019, David Schinazi wrote:

[...]

> We invite members of the community to read the latest draft and
> comment on list before our in-person meeting.
>

Daniel Kaiser asked me if I may read draft-ietf-dnssd-prireq-02 and
write some comments and I feel honoured to do it. I do research in the
area of system and network security and privacy and teach computer
networks and security at a University of Applied Sciences in
Germany. However, I have no deep knowledge about DNS-SD.

Comments:

,---- page 3, 4, and 5
| ASCII-Art diagrams
`----

I recognized only later that the person with the hat is the
adversary. Maybe it is useful to include some labels like "client 1",
"client 2", and "adversary" to avoid any confusion.

,---- page 3
| The adversary will be listening to the network traffic, trying to
| identify the visitors' devices and their activity.  Identifying devices
| leads to identifying people, either just for tracking people or as a
| preliminary to targeted attacks.
`----

If the adversary is listening to the network traffic, he/she will find
out if a client sends a print job to the printer. This argument is a bit
unclear to me.

,---- whole draft
| identity of the client.
`----

What is the identity of a client? IP address?

,---- page 5
| In addition to tracking the identity of the owner of the devices, the
| adversary is interested by the characteristics of the devices, such as
| type, brand, and model.  Identifying the type of device can lead to
| further attacks, from theft to device specific hacking.  The combination
| of devices worn by the same person will also provide a "fingerprint" of
| the person, allowing identification.
`----

An adversary that passively capture network traffic and an adversary
that actively generates fingerprints of a device are quite
different. IMHO, there should be a dedicated thread model section before
you describe the service discovery scenarios. What is the adversary
capable of and what do you include in the requirements and what is out of
scope.

,---- page 8
| 2.  Further, even if the application layer does not protect privacy, it
| is hard to record and analyse the unicast traffic (which most
| applications will generate) compared to just listening to the multicast
| messages sent by DNS-SD/mDNS.
`----

This argument is a bit unclear to me. Why is it hard to record and
analyse unicast traffic? It depends on the network of course. Again, it
would be useful to have thread model section. There are various attacks
to like CAM table overflow and Person-in-the-Middle (PitM) attacks that
would make that possible. Yes, it would be harder, but not impossible.

,---- page 9
| 4.  Security Considerations
`----

I'm missing considerations about Distributed Reflective Denial of
Service (DRDoS) attacks or amplification attacks. If we are talking
about general security requirements, I think it should be included. In
case of a UDP protocol, a requirement should be there the sender is
verified or the reply is as small as possible to avoid amplification.

,---- page 10
| 4.3.  Resistance to Dictionary Attacks
`----

I don't understand this security consideration. It is clear to me what a
dictionary attack is, but in what sense is this relevant for DNS-SD? Do
I miss already a possible privacy protection mechanisms that is missing?
Even if there are some sensitive information that were hashed to protect
the privacy, is a dictionary attack really a threat? In case of a
password, you have the password, which means you have access to a
website or a device. But for sensitive information? In that case it
would be better to encrypt the whole traffic.

,---- page  13
| 3.  DNS-SD messages transmitted by clients MUST NOT contain linkable
| identifiers that allow tracing client devices.
`----

Does this include the fingerprinting attack mentioned before?

,---- page 13
| 6.2.  Private Server Requirements
`----

Where are the requirements for the public server?

,---- page 13
| 2.  Servers MUST use privacy options available at lower layers, and for
| example avoid publishing static IPv4 or IPv6 addresses, or static IEEE
| 802 MAC addresses.
`----

Sure, one could use MAC address randomization or the temporary IPv6
address when the IPv6 privacy extension is enabled. But what about IPv4?
I don't see any way to avoid publishing the IPv4 address. Sure, one
could use IP spoofing, but this highly depends on the network and would
break [BCP 38]. Or do I misunderstand something?

General comment
===============

I have the feeling that the whole document is mainly focused on mDNS and
less about DNS. If this document is intended to be privacy and security
requirements about DNS-SD in general, I think DNS should be more
highlighted in the document.

Apart from these points, I approve of advancing the dnssd requirements
draft. Thanks for writing the draft and shedding light on this important
issue!

Best Regards
--
Prof. Dr. Florian Adamsky
Professor for IT-Security

Hochschule für Angewandte Wissenschaften Hof
Hof University of Applied Sciences
Alfons-Goppel-Platz 1 
95028 Hof / Saale
Germany

Room: C 122
Fon:  +49 (0) 9281 / 409 4860
GPG:  2E36 67A9 1521 744E 0D8E 0930 8CFB DEC8 C702 72AB

**2019: 25 Jahre Hochschule Hof + 10 Jahre BayIND**

---

From: Tim Wattenberg <[email-masked]>
Date: Fri, 22 Nov 2019 10:53:05 +0800

To relay what I’ve said in the meeting at mic:
I think in general the draft is ready to proceed, however I’d like to see some of the nits raised (e.g. by Florian A.) being addressed when proceeding towards publication.

Thanks, Tim

> Am 05.11.2019 um 06:29 schrieb David Schinazi <[email-masked]>:
> 
> Hi DNSSD enthusiasts,
> 
> Since there was interest in publishing the DNSSD Privacy Requirements work at
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd