[dnssd] Roman Danyliw's No Objection on draft-ietf-dnssd-prireq-05: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 04 March 2020 20:58 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnssd@ietf.org
Delivered-To: dnssd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23583A0871; Wed, 4 Mar 2020 12:58:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dnssd-prireq@ietf.org, dnssd-chairs@ietf.org, dnssd@ietf.org, David Schinazi <dschinazi.ietf@gmail.com>, dschinazi.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <158335552877.29262.18187945718837766095@ietfa.amsl.com>
Date: Wed, 04 Mar 2020 12:58:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/l1s88H8ZJZhsAerwtlIuabtgtUE>
Subject: [dnssd] Roman Danyliw's No Objection on draft-ietf-dnssd-prireq-05: (with COMMENT)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 20:58:49 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-dnssd-prireq-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks for this document.  Kuddos on the amazing ASCII art.

** Section 3.1.1. Per “Identifying devices leads to identifying people, either
just for tracking people or as a preliminary to targeted attacks.”, this didn’t
parse for me and the intent of the “just for tracking people” wasn’t clear.  Is
the following the intent:

“Identifying devices can lead to identifying people, either for surveillance of
these individuals in the physical world or as a preliminary step for a targeted
cyber attack.”

** Section 3.1.2.  Per “The requirement in that scenario is that the discovery
activity should not disclose the identify of either the client or the server”,
is something stronger more desirable?  For example, is there any desire to
thwart the discovery of the “business and social interactions” between the
device owners?

** Section 3.1.3  It seems as if all of the same challenges of Section 3.1.1
“identifying people” and using the information for a “targeted attack” apply
here too (but it’s said in a different way).  Is it worth link the same issues
across scenarios?

** Section 3.2.  Per “Information conveyed via multicast messages can be
obtained by an on-link attacker, while unicast messages are only available to
MITM attackers.”, please clarify why a passive on-link attacker can’t see the
unicast messages?

** Section 3.2.5.  Per “This combination of services and attributes will often
be sufficient to identify the version of the software running on a device”,
makes sense.  Is it worth adding that with this information and traffic
analysis, you might also be able to get identity (track people).