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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 05 March 2020 06:04 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 052C73A0D85; Wed, 4 Mar 2020 22:04:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 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: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158338827200.29413.5100659595596762657@ietfa.amsl.com>
Date: Wed, 04 Mar 2020 22:04:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/-v9cWG6upU1Z7FlX6PBfncpaKnk>
Subject: [dnssd] Benjamin Kaduk'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: Thu, 05 Mar 2020 06:04:32 -0000

Benjamin Kaduk 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:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-prireq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

   connected to the same network.  Consider for example a traveler
   wanting to upload pictures from a phone to a laptop when connected to
   the Wi-Fi network of an Internet cafe, or two travelers who want to

[both devices are on the same Wi-Fi, right?]

   Disclosing Information  In this document "disclosing information" is
      also focused on disclosure by data conveyed via messages on the
      service discovery protocol layer.

This is generic non-identity but still potentially sensitive data,
right?

Section 3.2

   kinds of means for making DNS-SD resource records available.  These
   means comprise but are not limited to mDNS [RFC6762], DNS servers
   ([RFC1033] [RFC1034], [RFC1035]), e.g. using SRP
   [I-D.ietf-dnssd-srp], and multi-link [RFC7558] networks.

nit: this "e.g." seems out of place.

Section 3.2.2

There is, of course, also no authentication requirement to claim a
particular instance name, so an active attacker can provide resources
that claim to be Alice's but are not.

Section 3.3.2

This sort of problem frequently ends up with a third-party "trusted
introducer", though it's not clear that mentioning this in the document
will add value.

3.4.2

I'm given to understand that for many radio technologies, multicast is
both effectively broadcast and has specific spectrum
requirements/properties that make it especially scarce, compared to
unicast spectrum.