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

Florian Adamsky <> Wed, 13 November 2019 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDE83120990 for <>; Wed, 13 Nov 2019 12:03:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z66gUw85jFwQ for <>; Wed, 13 Nov 2019 12:03:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2F65120942 for <>; Wed, 13 Nov 2019 12:03:00 -0800 (PST)
Received: from (localhost []) by localhost (Postfix) with SMTP id B202D6027A9 for <>; Wed, 13 Nov 2019 21:02:58 +0100 (CET)
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fadamsky) by (Postfix) with ESMTPSA id 89C596027A0 for <>; Wed, 13 Nov 2019 21:02:58 +0100 (CET)
References: <>
User-agent: mu4e 1.2.0; emacs 26.3
From: Florian Adamsky <>
In-reply-to: <>
Date: Wed, 13 Nov 2019 21:02:49 +0100
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2019.11.13.195417, AntiVirus-Engine: 5.68.0, AntiVirus-Data: 2019.11.13.5680001
Archived-At: <>
Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-prireq
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 20:17:51 -0000

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.


,---- 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

,---- 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

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

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**